Julius Stroffek wrote:
Hi Dan,
I am not very advanced in XA transactions. I went thought the Java
Transaction API and "Distributed Transaction Processing: The XA
Specification" from The Open Group.
One of my colleagues experiences problems when his application server
crashes and the locks held by the running XA transaction never get released.
With an XA transaction the connection (the logical connection as seen
by the application) can be closed and the transaction remain active.
Yes, but the transaction should be suspended before closing the logical
connection - by calling XAResource.end(xid, TMSUSPEND). Shouldn't it?
I don't know if the spec requires that. I don't believe Derby implements
it that way, I think you can open and close the logical JDBC connection
freely while in an active global transaction.
Since the XAResource object is accessed thought the call to
XAConnection.getXAResource and the underlying Connection object is the
same I would expect that the work between XAResource.start and
XAResource.end calls have to be done using the same Connection object?
Not the same JDBC Connection object, but the same underlying physical
connection. It's gets confusing in Derby because the physical connection
is a JDBC Connection object, but that is unique to Derby. If one
imagines another C based database system then most likely the XAResource
operations are not going through a JDBC Connection object, but instead
the database's wire protocol directly on a physical connection (socket).
Thus, if the socket will be closed before the call to XAResource.end
there is no way how to commit a change by the application. How else
should we know that the client application crashed?
Yes, but closing the logical JDBC Connection object by the application
should not be closing the underlying physical connection. Though I don't
know if that's the case here, I'm just trying to provide some background.
Is it possible to re-word the summary of DERBY-2220?
Yes, I have done that.
Thanks, always good to not scare folks with misleading bug descriptions :-)
Dan.
