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