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. From: Katherine Marsden [mailto:[email protected]] Sent: Wednesday, December 21, 2011 2:46 PM To: [email protected] Subject: Re: Problem with a deadlock with Derby 10.8.1.2 and Glassfish V2.1.1 On 12/21/2011 11:20 AM, Bergquist, Brett wrote: I'm having some trouble getting client side tracing to work. The connections are managed by Glassfish connection pool so I don't know where to set the traceDirectory and traceLevel properties. Can these be specified as properties like the password, etc. They can be set on the connection URL or with undocumented system properties, documented here #:) http://wiki.apache.org/db-derby/UndocumentedDerbyBehavior Looking at the info, again I am curious if there are corresponding server side traces in the derby.log. Also it would be interesting to see if there are at this point any XA Transactions in need of recovery in the database. Just exit your application and connect with ij and run: select * from SYSCS_DIAG.TRANSACTION_TABLE ;
