Why doesn't Datasource implement DataSource?

[Steven Grimm]

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

[Steven Grimm]

Ah, okay, answering my own question partly, I see that getConnection()
returns a DbConnection rather than a Connection. I'd forgotten about
that. So to pursue this further I could either:

- Implement a Datasource wrapper class that implements DataSource
- Or make DbConnection implement Connection, delegating to the
underlying Connection object

The latter seems more in keeping with the overall goal here of being
able to mix and match RIFE and external database libraries, but I am a
bit more nervous about passing DbConnection objects to non-RIFE code
than I am about passing in Datasource objects.

-Steve


Steven Grimm wrote:

> 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
>

_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Steven Grimm]

At the risk of talking to myself, I got something working. I ended up
making a new class (which I rather unimaginatively called
DatasourceDataSource) that takes a RIFE Datasource as input. It
implements javax.sql.DataSource. It returns instances of a DbConnection
wrapper (DbConnectionConnection) that delegates to either the
DbConnection object or to the underlying JDBC object where DbConnection
doesn't have an equivalent method.

I've posted my code at http://rifers.org/paste/show/1600 and
http://rifers.org/paste/show/1601 if anyone wants to check it out. I
have successfully wired this to iBatis and Quartz using Spring; I
haven't exhaustively tested it but it appears to work. I used it in
combination with the DatasourceFactory and
AutowiringParticipantSpringWeb classes which are both on the RIFE Wiki's
"Spring integration" page.

To make this work, I had to modify DbConnection to add a getter for the
underlying Connection object. That method is posted at
http://rifers.org/paste/show/1602 (not that there's much to it.)

The only place where DbConnectionConnection is more than just a simple
delegating wrapper is in the setAutoCommit() method, which calls
beginTransaction() or commit() on the DbConnection object. I *think*
that's the right implementation to allow non-RIFE code to interact with
RIFE transactions. (Less certain about the commit() call than the rest
of it, though.)

Is this approach reasonable?

-Steve

_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Geert Bevin]

Hi Steven,

I was going to look over this, but the pastebin entries have already  
been removed automatically. Could you maybe create an issue in Jira  
that contains the code snippets and use the improvement issue type.  
Like this nothing can get lost and it's easy to follow up on.

Thanks!

Geert

On 27 Aug 2006, at 09:14, Steven Grimm wrote:

> At the risk of talking to myself, I got something working. I ended  
> up making a new class (which I rather unimaginatively called  
> DatasourceDataSource) that takes a RIFE Datasource as input. It  
> implements javax.sql.DataSource. It returns instances of a  
> DbConnection wrapper (DbConnectionConnection) that delegates to  
> either the DbConnection object or to the underlying JDBC object  
> where DbConnection doesn't have an equivalent method.
>
> I've posted my code at http://rifers.org/paste/show/1600 and http://
> rifers.org/paste/show/1601 if anyone wants to check it out. I have  
> successfully wired this to iBatis and Quartz using Spring; I  
> haven't exhaustively tested it but it appears to work. I used it in  
> combination with the DatasourceFactory and  
> AutowiringParticipantSpringWeb classes which are both on the RIFE  
> Wiki's "Spring integration" page.
>
> To make this work, I had to modify DbConnection to add a getter for  
> the underlying Connection object. That method is posted at http://
> rifers.org/paste/show/1602 (not that there's much to it.)
>
> The only place where DbConnectionConnection is more than just a  
> simple delegating wrapper is in the setAutoCommit() method, which  
> calls beginTransaction() or commit() on the DbConnection object. I  
> *think* that's the right implementation to allow non-RIFE code to  
> interact with RIFE transactions. (Less certain about the commit()  
> call than the rest of it, though.)
>
> Is this approach reasonable?
>
> -Steve
>
> _______________________________________________
> Rife-devel mailing list
> Rife-devel@...
> http://lists.uwyn.com/mailman/listinfo/rife-devel
>

--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com


_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel

[Steven Grimm]

Done! I wasn't aware until yesterday that pastebin entries expired --
will post stuff like this somewhere more permanent from now on.

http://uwyn.com/issues/browse/RIFE-311

-Steve


Geert Bevin wrote:

> Hi Steven,
>
> I was going to look over this, but the pastebin entries have already
> been removed automatically. Could you maybe create an issue in Jira
> that contains the code snippets and use the improvement issue type.
> Like this nothing can get lost and it's easy to follow up on.
>
> Thanks!
>
> Geert

_______________________________________________
Rife-devel mailing list
Rife-devel@...
http://lists.uwyn.com/mailman/listinfo/rife-devel