Rickard,
You lost me when you started differentiating between JDBC 1.0 and
2.0 drivers. 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!
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?
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()
5) prepare()
6) commit()
If you close the connection after the end() it will either commit
or rollback (up to the DBMS, right?). Then prepare and/or commit will
operate on a closed connection and blow up.
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).
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.
Thanks,
Aaron
