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 JANUARY 30, 2022
Applies to:Oracle GlassFish Server - Version 2.1.1 and later
Information in this document applies to any platform.
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:
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:
- Enabled connection leak detection in a JDBC connection pool.
- Enabled connection leak reclamation in the same JDBC connection pool.
- 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