You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (Updated) (JIRA)" <ji...@apache.org> on 2012/02/17 19:36:00 UTC

[jira] [Updated] (DERBY-5560) Java deadlock between LogicalConnection40 and ClientXAConnection40

     [ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kathey Marsden updated DERBY-5560:
----------------------------------

      Issue & fix info: High Value Fix
               Urgency: Urgent
    Bug behavior facts: Crash,Performance,Seen in production  (was: Seen in production,Performance)
                Labels: derby_triage10_9  (was: )

Triage for 10.9. Marking Urgent, Crash (hang) and High Value Fix as we already have a patch.  Just need a volunteer to run tests and hopefully  add a test case and we can get this checked in.

                
> Java deadlock between LogicalConnection40 and ClientXAConnection40
> ------------------------------------------------------------------
>
>                 Key: DERBY-5560
>                 URL: https://issues.apache.org/jira/browse/DERBY-5560
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Client
>    Affects Versions: 10.8.2.2
>         Environment: Solaris 10
> Glassfish V2.1.1 
> ClientXADataSource connection pool setup to close all connections on any error
>            Reporter: Brett Bergquist
>              Labels: derby_triage10_9
>         Attachments: DERBY-5560.patch
>
>
> There is a Java deadlock between LogicalConnection40 and ClientXAConnection40.  The order of calls that cause the deadlock are:
> Thread 1
> ----
> LogicalConnection.close
> ClientPooledConnection.recycleConnection
> Thread 2
> ----
> ClientPooledConnection.close
> LogicalConnection.nullPhysicalConnection
> Thread 1 acquires a lock on the LogicalConnection and attempts to acquire a lock on the ClientPooledConnection
> Thread 2 acquires a lock on the ClientPooledConnection and attempts to acquire a lock on the LogicalConnection
> In production this occurs when one thread is committing a transaction and another thread is trying to close the connection.  This occurred because the Glassfish connection pool is setup to close all connections on any error on any connection and an error has been detected on another connection in the pool.

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