On 12/21/2011 12:40 PM, Bergquist, Brett wrote:
This also triggers another problem that I am having in production. If
these transactions are left in this state, Derby will build thousands
of transaction files in the "log" database. If the server is not
stopped and restarted soon after these start occurring, then it may
take days for Derby to boot the database.
Uncompleted XA transactions will persist even after the the server is
stopped and have to be recovered XAResource.recover() and told
explicitly whether to commit or rollback. An example of using
XAResource.recover() is in XATest testInterleavingTransactions(). Once
the core problem is determined, you should run an xa recovery
operation to clean up the residual transactions.
I assume that these are XA transactions that did not complete. I have
Glassfish to timeout transactions after 15 minutes but this appears
not to be working. I would like to set the
"derby.jdbc.xaTransactionTimeout" property but I am leery because of"
https://issues.apache.org/jira/browse/DERBY-4109
I can't really say to much about DERBY-4109 as we don't have a
reproduction and I don't understand the circumstances under which it
occurs, but in your case, I tend to think extending timeout is not
going to help as it seems you have hit a protocol exchange where the
server will never respond to the client.
Looking forward to seeing the excerpts from the client and server traces
after the deadlock and hearing how your simple deadlock test goes. If
you need a simple standalone template for XA to start from, I think
ReproDerby1016.java attached to DERBY-1016 might work.
Thanks
Kathey
