db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: 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 19:08:05 GMT
Is there any documentation on how "SanityManager.DEBUG" or how to build so that this is applicable?

From: Bergquist, Brett [mailto:BBergquist@canoga.com]
Sent: Saturday, March 16, 2013 1:19 PM
To: derby-dev@db.apache.org
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

Mime
View raw message