tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: DBCP is Single Threaded
Date Thu, 07 Nov 2013 21:44:09 GMT
On 07/11/2013 21:10, Christopher Schultz wrote:

> Can you describe the effective difference between my
> over-simplified description and what is implemented in commons-pool
> (ignoring thread-fairness, which I'll admit is a very useful
> feature)?

For starters, the relatively expensive validation process is outside
the sync. Given where this thread started, that is a key point.

Object creation, destruction, activation and deactivation are also all
outside the syncs. Creation and destruction are very likely to be
expensive as well (else why bother with a pool).

The key difference is that pool uses syncs to give a thread permission
to create an object, borrow an object, etc. Giving permission is very
quick. The actual action is taken outside of the syncs as that is slow
and expensive.

You will still hit a synchronisation bottleneck with very high
concurrency but I have a hard time believing most real world apps
would actually get anywhere near the concurrency levels you need to
reach to hit this bottleneck - if you use a recent version of Pool and
DBCP. If you use the versions of 4 years ago then hitting the
bottleneck is easy.

You can use the unit tests in jdbc-pool to examine the sorts of
concurrency levels you need to reach before you hit the bottleneck in

jdbc-pool and Pool2+DBCP2 remove the bottleneck entirely so in the
unliekly event you have an app with that much concurrency, a
bottleneck in the connection pool won't be an issue.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message