You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by yogesh hingmire <yo...@gmail.com> on 2013/11/07 16:58:51 UTC
DBCP is Single Threaded
While looking to upgrade to tomcat7, i understand the connection pool is a
major improvement. I read that
commons-dbcp is single threaded, in order to be thread safe commons-dbcp
locks the entire pool, even during query validation.
So as i understand, the connection pool will be locked when handing out new
connections and other threads which need connections from the pool will
wait until they are handed their respective connection?
Is my understanding right and if anyone could explain this better
Thank You
Yogesh
Re: DBCP is Single Threaded
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 11/7/13, 4:44 PM, Mark Thomas wrote:
> 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.
Agreed. Presumably, a Connection is being checked-out of the pool in
order to ... make some JDBC calls. Those are going to be way slower
than any of this synchronization we're discussing.
But, pathologically-speaking, a couple of hundred threads doing
nothing but repeatedly borrowing and returning JDBC connections are
going to expose a "horrible synchronization nightmare" in the
implementation. But that will be the case no matter what the
implementation, given the whole point of an object-pool.
> 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.
I'll have to look at how both of those libraries actually work under
the covers. I've never bothered to look...
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSfAxoAAoJEBzwKT+lPKRYVAIP/j72A6/+AHi89bG53rdBlvCI
wK550RM3udBt09lbhGZBWCe6qaj9sQdsgsp7MHO+ebj6/bx5bKdDQ+Pt4F28yUf7
ku3dubNjInTAB3xn25jY8MBPkzz82+8RrAsTc8QD0r/m/njsuRlM6EAu617GcI0q
PmAXlSLUmTAhSVAbPQ+ZqqdXA/eM8hu/NgT6ZyBIo/yez/jBrIzyGdHIGHKXsqRp
0N0ANH22o0uqgYms8tYpQgv1M/PJHLe9Br6e9aNPTJC9b3FZfq+fD/gbripGEnHC
GGqmT5+Pk3+n9bbPpp5JPJ1oDZY33SYE8CihJ7NBRrD14Egd3oqbotG8/LWmgDjk
lil/4Z0PuVpHPXzz3N+H5FGw83eJ4T8+vJs3EIxw4HrOSvwzyypmMFM6Z/UCmSbT
wCO4C47m84Omi3UX9r2ha9Wk7/oVh5O1g4nteHU1MJEO/BaiR7M/Q1BHAeKC4LSF
0zHwUVvgJzMHtCQBbaPYq2LynXiLk+RdWsIaC1ZBLAuBUVSThpv6NHau5xeKKHsx
gop897wXf3+t08js0JrfCRYq5ZglY2bO7DFXU6RFLwrRwVBGH6AV98us9a38nb8h
8XhK0GORm4p5QMRk2CBOOp0sKcSbihEhV3KHX4JymdnSvtdGXYMZuscBcpiwbMuV
nHZq/nfhfYXpIKKsPvMx
=8N8d
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Mark Thomas <ma...@apache.org>.
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
DBCP+Pool.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 11/7/13, 11:14 AM, Mark Thomas wrote:
> On 07/11/2013 16:03, Christopher Schultz wrote:
>> Yogesh,
>>
>> On 11/7/13, 10:58 AM, yogesh hingmire wrote:
>>> While looking to upgrade to tomcat7, i understand the
>>> connection pool is a major improvement. I read that
>>
>>> commons-dbcp is single threaded, in order to be thread safe
>>> commons-dbcp locks the entire pool, even during query
>>> validation.
>>
>>> So as i understand, the connection pool will be locked when
>>> handing out new connections and other threads which need
>>> connections from the pool will wait until they are handed
>>> their respective connection?
>>
>>> Is my understanding right and if anyone could explain this
>>> better
>>
>> That is correct. This is because the checkout method is
>> implemented like this (ignore syntax issues, this is psuedocode,
>> won't match method signatures, etc.):
>>
>> public synchronized Connection checkout() { // obtain connection
>> by whatever means necessary, // validate the connection, etc. }
>
> Huh?
>
> Have you even looked at the source for Commons Pool at any point
> in the last 4 years? (Commons Pool being the component that
> provides the object pooling used by Commons DBCP).
Sorry, I should have said it looks like this (which nobody would be
able to comprehend):
public /* not synchronized */ Object borrowObject() {
synchronized (this) {
// register this thread's desire for an object
}
allocate(); /* note: synchronized method */
for(;;) {
synchronized(this) {
// check that pool is open
}
// use a synchronized Latch object
if(poolExhausted {
synchronized (this) {
// take appropriate action
}
}
// use a synchronized Latch object
if(got object)
return object;
else
continue;
}
}
So... you're right: it's not one big synchronized method. Instead,
it's a mismash of monitor acquisitions and releases, many of which are
for "this". Mostly what all that acrobatics yields is the ability to
implement a fair thread-queuing system. In a fair thread-queuing
system, the effect is that ... all threads are serialized. So if 5
threads need objects from the pool, they will all wait in line.
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)?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSfAHQAAoJEBzwKT+lPKRYk+QP/iu8wIha5rntfSdRZ/HshdMG
KohNrU+l7SLXNqNAaI8505YbNusc+jy+PT++FtQj8WfLoViCVMiPPEpnoqsoeuK+
AHkrw2nQYyVDelY+7s/BWtFYuUaupLAeg2O8Hk+d/Dr18Toh3ZOq3+PStoCeMJX8
HjlkgHdQGmyQ7qjjTHtykidC5V8x16uTjSWEUyVFauWEM5ZkpC9dXXPE0rPrDXWi
cWgUG9QxTztGcEsMLinapuwueldTDCP9ZHOadi85tk0OE7efr8E72XTmfhYKUIy5
ZHjt2obJeyJinOXZq2VAy8iOxMPM7SrS7E2vFIkjAiP+/f6MX8emAGy1lZ76ajb7
6w4kZuXdFlCJhpDc70ZwX90Xh4uusY2msmRFJQr+JOPZ70b3vpX1nYagsn7sPZ8G
n1R+9vtNgRRjivusuYXJjUxdWZOZudMAEKAjCrW/vwXxJICbGu1qnDvnqBlsVtjZ
23wc3IqfNlsvTYLKHAsgdjYv7zZiRmmzE4BPqLcuyBn7FkSZ/9dgUTfZE8SDXrTG
2RAJdL3nmqgAxOXHzVDx7i4OmC7JLgdgtQ7pNyy7B8N/xUxLeqnuJRgFnQcaLc4C
jGDhseWmIdUx1ZxJAOJJzV+SPV6wy/HlQoRhxccb99LSWpneptqhizvcmfhtHBYk
a+/0l/3CdT0Y9SIRw73A
=OBJ4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Mark Thomas <ma...@apache.org>.
On 07/11/2013 16:03, Christopher Schultz wrote:
> Yogesh,
>
> On 11/7/13, 10:58 AM, yogesh hingmire wrote:
>> While looking to upgrade to tomcat7, i understand the connection
>> pool is a major improvement. I read that
>
>> commons-dbcp is single threaded, in order to be thread safe
>> commons-dbcp locks the entire pool, even during query
>> validation.
>
>> So as i understand, the connection pool will be locked when
>> handing out new connections and other threads which need
>> connections from the pool will wait until they are handed their
>> respective connection?
>
>> Is my understanding right and if anyone could explain this
>> better
>
> That is correct. This is because the checkout method is
> implemented like this (ignore syntax issues, this is psuedocode,
> won't match method signatures, etc.):
>
> public synchronized Connection checkout() { // obtain connection by
> whatever means necessary, // validate the connection, etc. }
Huh?
Have you even looked at the source for Commons Pool at any point in
the last 4 years? (Commons Pool being the component that provides the
object pooling used by Commons DBCP).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Yogesh,
On 11/7/13, 10:58 AM, yogesh hingmire wrote:
> While looking to upgrade to tomcat7, i understand the connection
> pool is a major improvement. I read that
>
> commons-dbcp is single threaded, in order to be thread safe
> commons-dbcp locks the entire pool, even during query validation.
>
> So as i understand, the connection pool will be locked when handing
> out new connections and other threads which need connections from
> the pool will wait until they are handed their respective
> connection?
>
> Is my understanding right and if anyone could explain this better
That is correct. This is because the checkout method is implemented
like this (ignore syntax issues, this is psuedocode, won't match
method signatures, etc.):
public synchronized Connection checkout()
{
// obtain connection by whatever means necessary,
// validate the connection, etc.
}
There's nothing particularly awkward, stupid or evil about the above
code. It's just that it uses "synchronized" for the whole method and
there are some performance penalties for doing that.
The term "single-threaded" is a bit misleading... of course DBCP is
thread-safe and multiple threads can access it, but there is
serialized access to the checkout method.
Tomcat-pool uses a different strategy for thread-safety that lends
itself to better performance under heavier loads.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSe7nvAAoJEBzwKT+lPKRYgg4P/iC9QSrDoeNxpleTp5Rli1H0
fMQF2jW6BfVn82ITbViaXBMW54r8Xci2h4+DjNEOicw7TSEGxXU9UPuCzfTIlGwL
JDBObNBFSOaeMVK4NwcIAVz0ZKzRErCieXgOueJBUCOUqZEOOTcf4MzMS21EK97A
FAxhiwmcuRoSSMXZY55fTaE5bkPCSrZgkSPSwcz42FHu2gzbGPKzo+OKkSagZrUK
Or+fwKDiMXmZyWmpyCG/fyDVIQv3KAuYDA6TPqYXIf6vB3z64HjTvTcU5kvRw8A5
IlBgnp4lI62LG2ofC6GdRT188hQz2RTxg3P4Mg3EyVuWgUY5Ndozxtb+UJs7fafV
9xHnnK64eRTfN7aKS3On6znu+RCXFXs5UMPvzNtR6GJl5moIUMjA6kII3IbTYAx+
EE3MVLm/sr5SwVuZEH2x0f45lu5QFeFch8IdlwIE6YMNZkZtZ+79SOhDsMr8ZbE2
M6/jDhAoQiiOH+asOLdf+7IUf85qrYUXm9Dd3DrZ9y+GSJLux+QOQVq8onBnQlA4
eW6AeZO9yb4qhRvkqUr5idDE77HNpwb8gtBsFlbHor8pSVbGIJQYSvYGraxSSy3/
UmmjKGkewTz/AcTMq85Czt1QpbESsWT86jwEsRIxAxxkRBFuP1TCSo1PUelkzW3i
pm6PUNE4bsEXblYQ5aOT
=7qzz
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Mark Thomas <ma...@apache.org>.
On 07/11/2013 16:08, Christopher Schultz wrote:
> Mark,
>
> On 11/7/13, 11:03 AM, Mark Thomas wrote:
>> On 07/11/2013 15:58, yogesh hingmire wrote:
>>> While looking to upgrade to tomcat7, i understand the
>>> connection pool is a major improvement. I read that
>>>
>>> commons-dbcp is single threaded, in order to be thread safe
>>> commons-dbcp locks the entire pool, even during query
>>> validation.
>
>> Where did you read that? While it might have been true of
>> earlier DBCP releases I'm fairly sure it is not true for current
>> releases.
>
> http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Introduction
>
>
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Introduction
>
> Bullet-point #1 in both cases.
Yep. Over 4 years out of date. I've made some edits.
The key messages are:
- jdbc-pool is faster than Commons DBCP
- at low concurrency there is little between them
- as concurrent borrow()s and return()s increase, the differential
increases
- how much difference it makes depends on the app so as with any
performance optimisation, test it first
- Tomcat 8 with DBCP2 should be a lot closer to jdbc-pool irrespective
of concurrency but I still expect jdbc-pool to be faster
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 11/7/13, 11:03 AM, Mark Thomas wrote:
> On 07/11/2013 15:58, yogesh hingmire wrote:
>> While looking to upgrade to tomcat7, i understand the connection
>> pool is a major improvement. I read that
>>
>> commons-dbcp is single threaded, in order to be thread safe
>> commons-dbcp locks the entire pool, even during query
>> validation.
>
> Where did you read that? While it might have been true of earlier
> DBCP releases I'm fairly sure it is not true for current releases.
http://tomcat.apache.org/tomcat-8.0-doc/jdbc-pool.html#Introduction
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html#Introduction
Bullet-point #1 in both cases.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSe7rwAAoJEBzwKT+lPKRY7TgQAJvqpR1vX9TRqx/QiQ3M4/ja
x7A6mPueIz0Xr1Ay4K/DT2Sd1d+2FkKIKOkEmb4bLa3bX3dcibeGrM/NOTg3E4wO
XEtsUqt79cQeBdodE2+JcBFPI811Gv2rAXDxP7X9zE7UAKNvzE3l84jLiiVR4UXS
JdzsDHj6plQw0j5qfbUq2QnanObd1gsww2Dff59RbRxn+o1b1prgcAzipmVPPOx5
R7sTrvjiSr5EbmCCATfhsQKPXoLG0hAqfjDjfGgRVA5Bu3NRNYKO70oh/BaCqURi
CztV1flZivvLvsNpyW5pCXBNLzN3kxJC6KP090r+M8voOw+u4OpthATKqxjAdjM1
5rXBWv7fAXlrsCZVst4zdoe9SBONBUEG8KqpyG50zBeKzYW4D6gvAcqod9aZBB+5
BEby3Cwe/dzf0+LzDJFNgWjTjPvDFQsj3//QY1PcUVYqxxO4J5mA834U4z5wSBkl
c6ZGv12cJ2WgvBLkzTIwXZkMng6k1tC2i1GcAPUl+VTbIZfN8H9pJsJFAxw2Kzsg
M9pl0D3ftueVAvMFV/nu8EEFttg15V/B3V2BH5qP/L4R0W38BCTQZCgVnvWjDo8b
UUdXJr9hkcJq57mJOIVxJoYiAzuLBDZeHXNOFRHnbGky5KAvAA7riRlrAsjK0mOy
LqS8xJJwyTPWrs+BX9ix
=lS+X
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: DBCP is Single Threaded
Posted by Mark Thomas <ma...@apache.org>.
On 07/11/2013 15:58, yogesh hingmire wrote:
> While looking to upgrade to tomcat7, i understand the connection pool is a
> major improvement. I read that
>
> commons-dbcp is single threaded, in order to be thread safe commons-dbcp
> locks the entire pool, even during query validation.
Where did you read that? While it might have been true of earlier DBCP
releases I'm fairly sure it is not true for current releases.
> So as i understand, the connection pool will be locked when handing out new
> connections and other threads which need connections from the pool will
> wait until they are handed their respective connection?
There are brief periods of locking but they do no last the entire of the
borrow() and the return() methods.
There is contention during borrow() and return() but you'll only notice
it on multi-core systems the borrow() / return() at high rates.
Tomcat 7 ships with jdbc-pool that does not have this contention.
DBCP2 also does not have this contention and is used (in snapshot form
as there has not yet been an official release) in Tomcat 8 onwards.
> Is my understanding right and if anyone could explain this better
The best way to understand exactly what is locked and when is to look at
the source.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org