You mean more general then useful to just me? :)
I've implemented a somewhat lite-weight wrapper around
Jdbc2PoolDataSource and ConnectionImpl provided by the
commons-jdbc2pool package, by creating derived classes for both of
these objects.
The problem that We've been having with torque is that many of the
torque convenience methods, created by foreign key relationships,
independently acquire their own connection to the database. The purpose
of the wrapper classes is to associate a connection to the current
thread. Then all subsequent calls to the DataSource's getConnection
method returns the already acquired Connection object.
An Example of its usage:
boolean dberr = true;
try
{
TDS.beginTrans();
List orders = user.getOrders();
for (int i=0; i<orders.size(); i++)
{
Order order = (Order)orders.get(i);
if (order.isShipped())
{
order.setbilled(true);
order.save();
Address orderAddress = order.getAddress();
Bill bill = new Bill();
bill.setAmount(order.getPrice());
bill.setAddress(orderAdress);
bill.save();
}
}
dberr = false;
}
finally
{
TDS.endTrans(dberr);
}
So the operation above would be performed within a single transaction.
TDS.endTrans(dberr) calls method TDS.commit() on false, and
TDS.rollback() on true.
Now, you could perform operations such as getAddress() by calling
AddressPeer.doSelect(crit, con), but I think this takes a away from
the general utility of Torque. The above method also provides a
greater degree of programmer safety since it will guarantees that all
DB operation are performed under the same transaction. Someone could
for example inadvertently add a getAddress() method into a
transactional operation. This mistake would be very hard to detect
with testing, but would lead to data corruption in rare cases.
This issue is also of concern since the addition of caching and
managers (Which I think is a most excellent addition). As a future
change I will make a simply wrapper in the manager classes so that if
the current thread is involved in a transaction, then the object get
will retrieve from the database (using the current transaction).
I've posted on this mailist before about this approach, but I don't
think it generated much interest. However, the package is simply a add
on package to Torque. Also, If a user does not use the TDS method
calls, then transaction behavior remains the default behavior.
To make a long story short, I needed the modification to the
DataSourceFactory so I can return a derived Jdbc2PoolDataSource to
Torque using the config property:
torque.dsfactory.dbname.factory=cc.base2.b2lib.database.TorqueTDSFactory
Anwyay, If there is interest I will submit this package and you guys
can take a look and see if you would like to incorporate it into
Torque or commons.
Byron
On Jun 28 09:01 2002, John McNally wrote:
> I will commit the patch when i make it through my queue again, if it
> doesn't happen sooner. Any chance the changes to
> Jdbc2PoolDataSource are generally useful?
>
> john mcnally
>
> On Fri, 2002-06-28 at 01:08, Byron Foster wrote:
> > I was wondering if someone would consider applying this patch. It
> > allows the creation of a derived class of
> > Jdbc2PoolDataSourceFactory to overide the implementation of the
> > method getJdbc2PoolDataSource(). This derived factory class can
> > then return a subclass implementation of Jdbc2PoolDataSource with
> > modified behavior.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
