Hi!
Aaron Mulder wrote:
> Unfortunately, it seems that a basic JDBC connection pool needs to
> pool Connection objects, while a transactional JDBC connection pool needs
> to pool XAConnection objects. And the only thing a Connection has in
> common with an XAConnection is java.lang.Object. Sigh.
> So it seems like the best way to approach this may be to create a
> generic *Object* pool, and then use the same basic pooling implementation
> in both cases, with small helpers to take the appropriate action when
> something is released from the pool (i.e. register with the
> TransactionManager). This would also entail a more generic interface for
> "last used" updates and probably a pooled object listener similar to
> ConnectionEventListener...
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
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
