-----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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
