Just wondering why RIFE's Datasource class doesn't implement the
javax.sql.DataSource interface.
Right now if I want to use, say, iBatis in a RIFE app, I end up having
to either point both of them at a container-supplied DataSource (and
disable RIFE's pooling since I need to use the container's at that
point) or let RIFE do its own connection pooling and use something like
Apache DBCP to maintain a second pool of connections for iBatis to draw
from. The former requires that I use a container that can manage
connection pools, and the latter doesn't work if I want to open a
transaction that contains both RIFE and iBatis database operations.
The ideal would be if I could just pass a RIFE Datasource to iBatis.
Then it would use RIFE's pooling (which could delegate to the
container's pooling if I wanted it to) and everything would work
smoothly even in non-pooling-capable containers.
This seems like a pretty easy change; I just want to make sure there's
not some reason it's a bad idea.
Also interesting (I think?) is that if Datasource implemented
DataSource, then a lot of RIFE's internal code could be changed to take
a DataSource instead of a Datasource, since in many places
getConnection() is the only method that's called anyway. That would open
the possibility of passing other kinds of DataSource objects into RIFE
as well as the other way around, which might be very useful in some
scenarios.
-Steve
_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel
