tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: DBCP is Single Threaded
Date Thu, 07 Nov 2013 21:55:54 GMT
-----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


Mime
View raw message