Oh and this is a timing issue. I set breakpoint at XATransactionState.cancel and step through the code, it does cleanup the transaction and locks correctly. If I let it run a full speed, it leaves the transaction and locks each time.
Note that this is with Derby 10.8.2.1 I also had another problem with is a deadlock between XATransactionState and EmbedConnection40 at one point when shutting down. I think there is a code path where locks are being obtained in different orders. XATransactionState.cancel is synchronized and so acquires a lock on it and then it calls methods on EmbedConnection some of which acquires locks on it. I believe there is also a code path where EmbedConnection acquires a lock itself and acquires a lock on XATransactionState. Thus the deadlock. I think that XATransactionState should always acquire a lock on the EmbedConnection first to fix this. 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
