On Tue, 23 May 2000, Rickard [iso-8859-1] �berg wrote:
> Hm..........................
>
> Not quite....
>
> Your pool should work with JDBC 2.0 drivers. JDBC 1.0 drivers are
> wrapped so that they look like JDBC 2.0 drivers. Note that XAConnection
> has a getConnection which returns a "real" connection. XAConnection is
> hence not a Connection (you cannot query it or anything), but merely a
> wrapper for a Connection and a XAResource. Considering this I think
> there is no problem: your pool should work with XAConnections.
> XAConnections are used to retrieve Connections. Now, if you're on a
> non-tx environment the only thing that would happen is that you never
> use the XAResource. It's still there, but you just never use it.
>
> This needs more thought, but I think the problem you described is
> illusory. It's not there.
>
> /Rickard
If you're in an entirely single-phase commit environment (outside
of an app server) it would be a little bizarre to create this XAConnection
abstraction on top of the Connections and then not use any of those
features. It would just be an extra later of wrapping. Also, there would
be overhead looking for non-existant transaction managers and potentially
runtime errors if JNDI is not available.
So I guess you're right that there's another approach, but we'd
have to be very conscious to make the JNDI/transaction code modular, to
return connections to the pool at the appropriate time (waiting for
end() or not), and to minimize the extra overhead.
Aaron
