Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <527C01D2.2040307@christopherschultz.net>
Date: Thu, 07 Nov 2013 16:10:42 -0500
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: DBCP is Single Threaded
References: 
 <CAJgUXc0RtSQpk0vczM-mNJqWuDzovyUNm0CavRChsbSq1VMGfg@mail.gmail.com>
 <527BB9EF.5020809@christopherschultz.net> <527BBC50.10101@apache.org>
In-Reply-To: <527BBC50.10101@apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

-----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