On 8/23/2011 5:21 AM, Bergquist, Brett wrote:
I guess I was under the assumption that it would go away if I booted the
database clean. It seems to me that a database that has been stopped and
booted clean would invalidate an existing transactions and clean them up. Is
this not the case with XA transactions?
In A two phase commit XA transaction, if there is a crash between the
prepare and the final commit or rollback, there is not a way for Derby
to know whether the overall distributed transaction was committed or
rolled back, so even after the database is rebooted, the transaction
remains in the prepared state and has to be manually recovered and
appropriately committed or rolled back to match the global transaction.
The prepare just guarantees that either commit or rollback will work.
The JTA spec which provides the Java interfaces for XA transactions is
based on the open group XA Specification, which is a good resource for
understanding XA concepts.
https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=c193
HTH
Kathey
PS. There is a single phase commitin XAResource.commit(Xid xid, boolean
onePhase) if your transaction involves just a single database and that
is all you require, but I don't know if you have overall handling of the
XA transaction processing.
