My Oracle Support Banner

JDBC Leak Detection in Oracle Glassfish Server Can Lock the Connection Pool When Attempting to Reclaim an Active Connection (Doc ID 1281608.1)

Last updated on OCTOBER 26, 2020

Applies to:

Oracle GlassFish Server - Version 2.1.1 and later
Information in this document applies to any platform.
***Checked for relevance on 15-Aug-2013***


This problem results in threads blocking on a JDBC Connection Pool when the connection pool is trying to reclaim a JDBC connection that has exceeded the pool's leak detection timeout setting. 

While the connection pool is locked, no other request threads can either obtain or return connections to the pool.  This results in those requests appearing to hang while they wait to access the pool.

This problem is best seen in a Java thread dump taken at the point the hang has been noticed.  Please refer to <Note:1213467.1> for details on how to capture information for a hung application server that includes information on capturing a Java thread dump.

The first symptom is a report of a potential leaked connection, similar to this:

[#|2011-01-14T17:36:30.892+0000|WARNING|sun-appserver2.1.1|javax.enterprise.resource.resourceadapter|_ThreadID=<ID>;_ThreadName=<Name>;ConnectionPoolName=OraclePool;_RequestID=<RequestID>;|A potential connection leak detected for connection pool OraclePool. The stack trace of the thread is provided below :
... application specific portion of stack omitted for brevity

In the Java thread dump the blocked request threads will look similar to the following thread stack:

"httpSSLWorkerThread-50001-127" daemon prio=x tid=<tid> nid=<nid> waiting for monitor entry [.....]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at com.sun.enterprise.resource.AbstractResourcePool.getResourceFromPool(
    - waiting to lock <xxxxxx> (a com.sun.enterprise.resource.SJSASResourcePool)
    at com.sun.enterprise.resource.AbstractResourcePool.getUnenlistedResource(
    at com.sun.enterprise.resource.AbstractResourcePool.internalGetResource(
    at com.sun.enterprise.resource.AbstractResourcePool.getResource(
    at com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(
    at com.sun.enterprise.resource.PoolManagerImpl.getResource(
    at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(
    at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(
    at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(
    at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(
    at com.sun.gjc.spi.base.DataSource.getConnection(
    ... application specific portion of stack omitted for brevity

In the above output, you can see that the thread is trying to lock object <0x85225f90>, which is an instance of SJSASResourcePool, which extends the AbstractResourcePool class. 

Searching the rest of the Java thread dump for a thread that has this object locked, you should find a TimerThread which is trying to close the physical JDBC connection from the method com.sun.gjc.spi.ManagedConnection.destroy()

"Timer-5" daemon prio=x tid=<tid> nid=<nid> waiting for monitor entry [....]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at oracle.jdbc.driver.PhysicalConnection.close(
    - waiting to lock <xxxxxx> (a oracle.jdbc.driver.T4CConnection)
    at oracle.jdbc.pool.OraclePooledConnection.close(
    - locked <xxxxxx> (a oracle.jdbc.driver.T4CXAConnection)
    at com.sun.gjc.spi.ManagedConnection.destroy(
    at com.sun.enterprise.resource.ConnectorAllocator.destroyResource(
    at com.sun.enterprise.resource.AbstractResourcePool.destroyResource(
    at com.sun.enterprise.resource.AbstractResourcePool.potentialConnectionLeakFound(
    - locked <xxxxxx> (a com.sun.enterprise.resource.SJSASResourcePool)
    at com.sun.enterprise.resource.AbstractResourcePool.access$100(
    at com.sun.enterprise.resource.AbstractResourcePool$
    at java.util.TimerThread.mainLoop(

The thread name reporting the potential leak, "Timer-5", and the blocked thread are the same.


For this problem to be encountered you need to have:

  1. Enabled connection leak detection in a JDBC connection pool.
  2. Enabled connection leak reclamation in the same JDBC connection pool.
  3. Have a thread executing a SQL statement created from the connection at the point the application has had the connection for longer than the leak detection timeout.  Potentially the SQL statement could be running much more slowly than normal, perhaps due to performance issues on the database that its running on.


To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.