[
https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Bergquist updated DERBY-5560:
-----------------------------------
Attachment: DERBY-5560.patch
After looking at the code and locking patterns between the LogicalConnection
and ClientPooledConnection, I have determined that the safest change is to just
change the LogicalConnection.close to first synchronize on the
ClientPooledConnection.
The ClientPooledConnection first synchronizes on itself and then calls the
LogicalConnection.nullPhysicalConnection which synchronizes on the
LogicalConnection. So that lock pattern is ClientPooledConnection and then
LogicalConnection.
The patch changes the LogicalConnection.close method to do the same. The patch
makes the method not synchronized and then first synchronizes on the
ClientPooledConnection and then the LogicalConnection. The pattern is now the
same.
> 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
> 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
