db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
Date Wed, 15 Feb 2012 02:23:59 GMT

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

Mike Matrigali commented on DERBY-5552:
---------------------------------------

i tried to review the change, but am not familar with the assumptions at this level.  I agree
with your concern that previous comment
seems to be indicating it wants to disable the connection.  The comment "disable use of the
connection until it is cleaned up.", seems
to indicate maybe it meant to reenable it after the work of:
                    notifyAll();
                    associationState = TRO_FAIL;
                    if (SQLState.DEADLOCK.equals(se.getMessageId()))
                        rollbackOnlyCode = XAException.XA_RBDEADLOCK;
                    else if (se.isLockTimeout())
                        rollbackOnlyCode = XAException.XA_RBTIMEOUT;
                    else
                        rollbackOnlyCode = XAException.XA_RBOTHER;

I reviewed the other comments in the issue, and agree with Brett's analysis of calls to cleanupOnError,
and the single thread nature.

Does anyone think it worthwhile to null out the connection, perform the above code, and then
reset the connection?


                
> 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
>         Attachments: DERBY-5552-p1.patch, DERBY-5552-p2.patch, ReproDerby5552LockTimeout.java,
appserverstack.txt, client.tar.Z, 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

        

Mime
View raw message