|
»
« Return to Thread: Why doesn't Datasource implement DataSource?
Re: Why doesn't Datasource implement DataSource?
by Steven Grimm
::
Rate this Message:
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
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
« Return to Thread: Why doesn't Datasource implement DataSource?
| Free embeddable forum powered by Nabble | Forum Help |
