Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Thu, 23 Feb 2012 23:45:48 +0000 (UTC)
From: "Kathey Marsden (Commented) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <398280572.12642.1330040748812.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1012228928.39487.1324569330923.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5552) Derby threads hanging when using
 ClientXADataSource and a deadlock or lock timeout occurs
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215209#comment-13215209 ] 

Kathey Marsden commented on DERBY-5552:
---------------------------------------

Running derbyall I see one failure a test specifically for this case expecting no connection.
$ cat xaSimpleNegative.diff
*** Start: xaSimpleNegative jdk1.7.0 derbyall:xa 2012-02-23 14:23:29 ***
202 del
< ERROR 08003: No current connection.
202a202,204
> A         |B
> ----------------------
> ERROR 40XL1: A lock could not be obtained within the time requested
Test Failed.
*** End:   xaSimpleNegative jdk1.7.0 derbyall:xa 2012-02-23 14:23:45 ***


Specifically the master xaSimpleNegative.out shows we were expecting the connection to go away after the lock timeout. It also shows that we expected to be able to  still explicitly rollback the transaction. I think that is not something that would be persistent as the transaction is no longer in the transaction table.

ij(XA)> -- ERROR: deadlock, transaction trashed
select * from APP.negative;
A         |B          
----------------------
ERROR 40XL1: A lock could not be obtained within the time requested
ij(XA)> -- ERROR: should have no connection underneath
select * from APP.negative;
ERROR 08003: No current connection.
ij(XA)> -- ERROR: should have no connection underneath and xid 2 is gone
xa_end xa_suspend 2;
IJ ERROR: XA_RBTIMEOUT 
ij(XA)> -- ERROR: should have no connection underneath and xid 2 is gone
xa_end xa_fail 2;
IJ ERROR: XA_RBTIMEOUT 
ij(XA)> xa_rollback 2;
ij(XA)> disconnect;

So I am not sure exactly what to think.   Maybe it would be worthwhile to see what other databases do.

As an aside in my google research, I noticed I actually asked about this back in 2004!
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200411.mbox/%3C4186AA22.7000305@Sourcery.Org%3E

                
> Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
> -----------------------------------------------------------------------------------------
>
>                 Key: DERBY-5552
>                 URL: https://issues.apache.org/jira/browse/DERBY-5552
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.8.1.2
>         Environment: Solaris 10, Glassfish V2.1.1,
>            Reporter: Brett Bergquist
>            Assignee: Kathey Marsden
>            Priority: Blocker
>              Labels: derby_triage10_9
>         Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552LockTimeout.java, appserverstack.txt, client.tar.Z, derby-5552_withexpanded_test_diff.txt, derby-5552_withtest_diff.txt, derby-5552_withtest_diff.txt, derby.log, derbystackatshutdown.txt, execute.patch, transactionsleft.txt
>
>
> The issue arrives when multiple XA transactions are done in parallel and there is either a lock timeout or a lock deadlock detected.  When this happens the connection is leaked in the Glassfish connection pool and the client thread hangs in "org.apache.derby.client.netReply.fill(Reply.java:172)".  
> Shutting down the app server fails because the thread has a lock in "org.apache.derby.client.net.NetConnection40" and another task is calling "org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214)" which is waiting for the lock.
> Killing the appsever using "kill" and then attempting to shutdown Derby network server causes the Network Server to hang.  One of the threads hangs waiting for a lock at "org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525)" and the "main" thread has this locked at "org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242)" and it itself is waiting for a lock which belongs to a thread that is stuck at "org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) which is in the TIMED_WAITING state.
> Only by killing the Network Server using "kill" is possible at this point.
> There are transactions left even though all clients have been removed.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira