On 12/21/2011 12:04 PM, Bergquist, Brett wrote:
>
> Nothing in the Derby log other than it logging a deadlock with the 
> statements and a lock timeout with its statements and it indicating 
> that cleanup had started and completed.
>
> I will enable tracing with the documented (undocumented system 
> property).  Thanks for that information!
>
> I will check for the XA transactions the next time I reproduce this.
>
> Maybe you could point me into the correct area to look.  This seems to 
> be triggered either through a lock timeout or a deadlock.   The 
> connection that this is occurring through is an XA connection.   I see 
> the logging of this in the server log but I am trying to find out 
> where that would be logged from.   It seems after this occurs and 
> because of the way connection pool is being validated and recreated on 
> error by Glassfish (configured to do so), it gets into this state.  
> What I don't understand is why this type of error would cause the 
> connection to appear to be invalid and I am trying to work through 
> both the Glassfish source and the Derby source to find out.   The 
> connection is correctly handling other errors such as a duplication 
> trying to be inserted and this does not trigger the connection to 
> appear to be invalid.    So I am trying to understand why a lock 
> timeout or deadlock detection might do so.
>
> This problem has only cropped up recently when they started performing 
> multiple requests that I know have a deadlock path through them.  I 
> can fix that problem later but this is a system level problem that I 
> need to resolve.
>
> I really do appreciate the help and guidance and am willing to try to 
> work though this.   I have to figure this out and either patch 
> Glassfish or Derby in any case as my customer (think very very large 
> wireless carrier) is getting pretty PO'ed.
>
The one thing I think of specifically with a deadlock is that it will 
automatically rollback the victim transaction and that might throw off 
this client logic regarding the state of the server.    But I would 
think if there were just a simple problem with deadlocks it would have 
showed up before now. That said I don't see any specific tests in our XA 
tests: org.apache.derbyTesting.functionTests.tests.jdbapi.XATest or 
org.apache.derbyTesting.functionTests.tests.jdbcapi.XATransactionTest  
that test XAConnections with deadlocks.

   Is this a local transaction on an XA connection or a real XA 
transaction with two phase commit?

You might want to try to test and an XAConnection with  a simple 
deadlock case locally to see if that pops a reproduction.   
org.apache.derbyTesting.functionTests.tests.lang.DeadlockDetectionTest 
and org.apache.derbyTesting.functionTests.tests.lang have  some examples 
of deadlocks.

HTH,

Kathey