Hi!
Aaron Mulder wrote:
> 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.
Even if you're in a tx environment you will have to be ready for usage
of the pool without tx's running, so that's no problem.
I think that the overhead is minimal, but that you might have to do
things twice if you do not work on XAConnections in the core of the pool
(as you note).
But you're of course welcome to prove me wrong :-)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
