Is there any documentation on how "SanityManager.DEBUG" or how to build so that this is applicable?
From: Bergquist, Brett [mailto:[email protected]] Sent: Saturday, March 16, 2013 1:19 PM To: [email protected] Subject: Where to look in the code to find out why XA transactions and database locks are not be cleaned up I have a reproducible case where I set the derby.xaTransactionTimeout to a really low value (10 seconds) and then initiate a transaction that takes longer. The transaction is canceled and I can see this in the derby.log, however the transaction remains in the database as determined by: select * from syscs_diag.transaction_table where status != 'IDLE' which still shows the transaction with an XID and a <null> GLOBAL_XID. Querying the lock table by: select * from syscs_diag.lock_table shows the many locks still owned by the XID. Both of these never go away until a restart of Derby. So I am going to fix this but I need to know where to look on what should be called when the transaction is canceled. I am looking at XATransactionState.java which is where the timer initiates the cancel and I see it canceling any running statement and then performing a "conn.xa.rollback()" and obviously these are not cleaning up everything that needs to be cleaned up. Any help in pointing at the right direction will be greatly appreciated. Brett
