[
https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176800#comment-13176800
]
Brett Bergquist commented on DERBY-5560:
----------------------------------------
>From my looking at the code, the ClientPooledConnection is the owner of the
>LogicalConnection. It is the one that creates the LogicalConnection. So I am
>thinking that the synchronization on the ClientPooledConnection should be done
>before synchronization on the LogicalConnection. The LogicalConnection has a
>reference to the ClientPooledConnection (pooledCollection_) that is never set
>to null once it is initialized. I am thinking that the
>LogicalConnection.close could be rewritten as:
public void close() throws SQLException {
try {
synchronized (pooledConnection_) {
synchronized (this) {
// we also need to loop thru all the logicalStatements and
close them
if (physicalConnection_ == null) {
return;
}
if (physicalConnection_.agent_.loggingEnabled()) {
physicalConnection_.agent_.logWriter_.traceEntry(this,
"close");
}
if (physicalConnection_.isClosed()) // connection is closed
or has become stale
{
pooledConnection_.informListeners(new SqlException(null,
new ClientMessageId(
SQLState.PHYSICAL_CONNECTION_ALREADY_CLOSED)));
} else {
physicalConnection_.checkForTransactionInProgress();
physicalConnection_.closeForReuse(
pooledConnection_.isStatementPoolingEnabled());
if (!physicalConnection_.isGlobalPending_()) {
pooledConnection_.recycleConnection();
}
}
physicalConnection_ = null;
pooledConnection_.nullLogicalConnection();
}
}
} catch (SqlException se) {
throw se.getSQLException();
}
}
First synchronize on the the ClientPooledConnection and then on the
LogicalConnection. This will be in the same order as
ClientPooledConnection.close() does.
> 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
>
> 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
