db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Katherine Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Problem with a deadlock with Derby 10.8.1.2 and Glassfish V2.1.1
Date Wed, 21 Dec 2011 21:31:47 GMT
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

Mime
View raw message