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 18:16:49 GMT
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

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: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

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