Hi!
Aaron Mulder wrote:
> You lost me when you started differentiating between JDBC 1.0 and
> 2.0 drivers.
Yep, it is a bit confusing. Having only JDBC 2.0 drivers would be much
easier...
> I didn't think JDBC 2.0 drivers necessarily implemented any
> of the stuff discussed in the JDBC standard extension document. I didn't
> think the JDBC 2.0 drivers were inherently aware of transactions or the
> application server in any meaningful way. But in one of your responses
> you implied that JDBC 2.0 drivers already had an XAResource. Help!
Databaser drivers that want to support XA properly should implement
XAConnection and XADataSource. *You* as a pool creator/app server vendor
does not have to do this. All you have to do is provide the layer
between the driver and the end user, part of which is to make sure that
the connections are tied to the transaction manager properly.
> On a related note, you noted the ConnectionEventListener in
> relation to XAConnections. I'm not clear on how this would be used. What
> would be registered as a ConnectionEventListener, and what actions would
> it take in response to close or error events?
The pool is registered as a connection event listener. When the user
does close() on the connection that is provided by
PooledConnection.getConnection, you as a pool get a notification of this
so that you may mark it as available in the pool again.
> And the last question (for now) is about closing connections /
> returning connections to the pool. I believe you said that a connection
> could be closed or returned to the pool when the TransactionManager called
> the end() method on the XAResource (this is where you mentioned JDBC 2.0
> drivers), but I still disagree with this. Let's forget the pooling, and
> imagine that the connection is closed when end is called. The XAResource
> sequence seems to be:
>
> 1) create
> 2) start()
> 3) do work
> 4) end()
At which point this connection can be returned to the pool.
> 5) prepare()
> 6) commit()
The devil is in the details. Look in XAResource and you will see that
both prepare commit and rollback is called with the tx Xid. Because of
this the connection in 1-4 and 5/6 doesn't have to be the same. It can
be a different one. After end() it is not associated with a tx anymore.
> If you close the connection after the end() it will either commit
> or rollback (up to the DBMS, right?).
Incorrect. If you call end() it is disassociated with the tx, as
specified in XAResource. If you close a connection that is not
associated with a tx, why would that affect some tx? It doesn't.
> Then prepare and/or commit will
> operate on a closed connection and blow up.
As above, prepare/commit/rollback can be done on any connection from the
pool (and all connections in the pool are by definition open(!)).
> If we return a connection to the pool instead of closing, then it
> could be checked out and used by a different transaction before the
> original transaction called commit, which would result in committing the
> work of two transactions (or one and part of another).
Incorrect. A connection can be used for any number of tx's, but it is
only associated with one tx at a time (through start/end call pairs).
> So this is why I think we need to stop the connection from being
> closed or returned to the pool until the commit or rollback is called on
> the XAResource.
Incorrect, as discussed above.
Are you with me? These are rather difficult stuff until you see how tx's
and connections tie together. Read the JTA spec until your eyes bleed.
It will appear to you eventually ;-)
/Rickard
--
Rickard �berg
@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
