db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Rollback is not executed only for XA sessions after the socket is closed.
Date Wed, 10 Jan 2007 18:17:19 GMT
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 :-)


View raw message