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:10:42 GMT
-----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


Mime
View raw message