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 "Brett Bergquist (Created) (JIRA)" <ji...@apache.org> on 2011/12/28 16:12:30 UTC
[jira] [Created] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
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
[jira] [Updated] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Brett Bergquist (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178778#comment-13178778 ]
Brett Bergquist commented on DERBY-5560:
----------------------------------------
I want to help more but am just coming up to speed on JUnit and Derby testing.
I would like to help improve the testing of this but it may take a couple of weeks before I am useful. My time is limited because I just spent the last two weeks trying to find and fix the problems that I did. Now my regularly scheduled day job tasks that were delayed are beckoning.
I will make an attempt to help in providing better testing however.
> 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
[jira] [Updated] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Kathey Marsden (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Kathey Marsden (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176764#comment-13176764 ]
Kathey Marsden commented on DERBY-5560:
---------------------------------------
Some discussion regarding this issue is in this thread:
http://old.nabble.com/Could-someone-give-me-some-guidance-on-DERBY-5560-to33046146.html
> 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
[jira] [Issue Comment Edited] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Brett Bergquist (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178772#comment-13178772 ]
Brett Bergquist edited comment on DERBY-5560 at 1/3/12 3:19 PM:
----------------------------------------------------------------
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.nullLogicalConnection 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.
was (Author: bbergquist):
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
[jira] [Commented] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Bryan Pendleton (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13178776#comment-13178776 ]
Bryan Pendleton commented on DERBY-5560:
----------------------------------------
Your approach seems reasonable to me, thanks for the clear explanation.
I think it would be worth adding some comments to the class-level comments for
the two classes, to note the locking order convention we've adopted.
How could we improve our test suite in this area, to make it more likely that
problems like these would show up during development testing, rather than
in production applications? Do you have any time to try to improve the tests?
> 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
[jira] [Commented] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Brett Bergquist (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13419080#comment-13419080 ]
Brett Bergquist commented on DERBY-5560:
----------------------------------------
I still am not able to help provide tests, but this is an important fix as it does occur in production. I have been running with this patched in place at a large telecom running under Glassfish and have not seen this issue since the patch was put in place.
In upgrading to 10.9.1.0, I have had to reapplied this patch and provide a custom build.
> 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
[jira] [Commented] (DERBY-5560) Java deadlock between
LogicalConnection40 and ClientXAConnection40
Posted by "Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176749#comment-13176749 ]
Brett Bergquist commented on DERBY-5560:
----------------------------------------
Partial stack trace of first thread:
at org.apache.derby.client.ClientPooledConnection.recycleConnection(ClientPooledConnection.java:353)
- waiting to lock <0xfffffffc80843f18> (a org.apache.derby.client.ClientXAConnection40)
at org.apache.derby.client.am.LogicalConnection.close(LogicalConnection.java:91)
- locked <0xfffffffc85f35508> (a org.apache.derby.client.am.LogicalConnection40)
at com.sun.gjc.spi.ManagedConnection.transactionCompleted(ManagedConnection.java:492)
at com.sun.gjc.spi.XAResourceImpl.commit(XAResourceImpl.java:88)
at com.sun.jts.jtsxa.OTSResourceImpl.commit_one_phase(OTSResourceImpl.java:166)
at com.sun.jts.CosTransactions.RegisteredResources.commitOnePhase(RegisteredResources.java:1575)
at com.sun.jts.CosTransactions.TopCoordinator.commitOnePhase(TopCoordinator.java:2949)
at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:317)
at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:250)
- locked <0xfffffffc8597bea0> (a com.sun.jts.CosTransactions.TerminatorImpl)
at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
at com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
at com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1003)
at com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:398)
Partial stack trace of second thread:
at org.apache.derby.client.am.LogicalConnection.nullPhysicalConnection(LogicalConnection.java:64)
- waiting to lock <0xfffffffc85f35508> (a org.apache.derby.client.am.LogicalConnection40)
at org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:204)
- locked <0xfffffffc80843f18> (a org.apache.derby.client.ClientXAConnection40)
at org.apache.derby.client.ClientXAConnection.close(ClientXAConnection.java:139)
- locked <0xfffffffc80843f18> (a org.apache.derby.client.ClientXAConnection40)
at com.sun.gjc.spi.ManagedConnection.destroy(ManagedConnection.java:276)
at com.sun.enterprise.resource.ConnectorAllocator.destroyResource(ConnectorAllocator.java:175)
at com.sun.enterprise.resource.AbstractResourcePool.destroyResource(AbstractResourcePool.java:986)
at com.sun.enterprise.resource.AbstractResourcePool.emptyPool(AbstractResourcePool.java:1635)
- locked <0xfffffffc72af99c0> (a com.sun.enterprise.resource.SJSASResourcePool)
at com.sun.enterprise.resource.AbstractResourcePool.doFailAllConnectionsProcessing(AbstractResourcePool.java:1213)
at com.sun.enterprise.resource.AbstractResourcePool.resourceErrorOccurred(AbstractResourcePool.java:1163)
- locked <0xfffffffc72af99c0> (a com.sun.enterprise.resource.SJSASResourcePool)
at com.sun.enterprise.resource.PoolManagerImpl.putbackResourceToPool(PoolManagerImpl.java:445)
at com.sun.enterprise.resource.PoolManagerImpl.resourceErrorOccurred(PoolManagerImpl.java:411)
at com.sun.enterprise.resource.ConnectorAllocator$ConnectionListenerImpl.connectionErrorOccurred(ConnectorAllocator.java:98)
at com.sun.gjc.spi.ManagedConnection.connectionErrorOccurred(ManagedConnection.java:662)
at com.sun.gjc.spi.ManagedConnectionFactory.getInvalidConnections(ManagedConnectionFactory.java:249)
at com.sun.enterprise.resource.AbstractConnectorAllocator.getInvalidConnections(AbstractConnectorAllocator.java:99)
at com.sun.enterprise.resource.AbstractConnectorAllocator.isConnectionValid(AbstractConnectorAllocator.java:111)
at com.sun.enterprise.resource.AbstractResourcePool.isConnectionValid(AbstractResourcePool.java:722)
at com.sun.enterprise.resource.AbstractResourcePool.getUnenlistedResource(AbstractResourcePool.java:668)
at com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(AbstractResourcePool.java:609)
at com.sun.enterprise.resource.AbstractResourcePool.getResource(AbstractResourcePool.java:458)
at com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
at com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:337)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
> 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