db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject Where to look in the code to find out why XA transactions and database locks are not be cleaned up
Date Sat, 16 Mar 2013 17:18:57 GMT
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

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.


View raw message