Bug 56805 - datasource.getConnection() may be unnecessarily blocked by the PoolCleaner thread
Summary: datasource.getConnection() may be unnecessarily blocked by the PoolCleaner th...
Status: NEW
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: PC Mac OS X 10.4
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2014-08-02 22:27 UTC by Bertrand Renuart
Modified: 2014-08-02 22:28 UTC (History)
1 user (show)

TestCase (4.17 KB, text/plain)
2014-08-02 22:28 UTC, Bertrand Renuart

Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Renuart 2014-08-02 22:27:05 UTC
The getConnection() method invokes borrowConnection(). The later polls the idle collection for available existing connections. If a connection is available, the method attempts to lock() it to gain exclusive access. It may happen the connection is already locked by the PoolCleaner for validation for instance. In this case, getConnection() will have to wait until the validation is completed - even if other idle connections are available.

The attach test case illustrates the phenomenon. The pool starts with two connections and uses a custom Validator waiting for 1000ms to simulate a slow validation process. An attempt to get a connection from the pool is made when the first connection is being validated by the PoolCleaner. At the end, the test shows that the application gets the connection after 1000ms: it had to wait for the completion of the validation although another connection was immediately available in the idle pool.

The outcome becomes even worst if the validation never returns (because of a missing validationQueryTimeout - see bug 56804): in this case, the application thread is blocked forever as well.

Ideally, the borrow connection logic should somehow ignore connections under validation and immediately consider the other connections available in the pool.
Comment 1 Bertrand Renuart 2014-08-02 22:28:09 UTC
Created attachment 31867 [details]