I have ran into a problem with the ConnectionPool class from Turbine 2.x. I
noticed the problem while making many requests to a pool configured with a
maximum of 5 connections. What happens is the following:
1. All 5 connections go into use.
2. Several threads are waiting for a connection to be returned to the
stack.
3. 1 connection is returned and notify() is called - line 655
4. One of the threads is awakened and is now actively competing for the
lock.
5. A new thread (non-waiting) is created and gets the lock before the
awakened thread.
6. The new thread takes the newly available connection from the stack.
7. The awakened thread now gets the lock and discovers that there is no
available connection in the pool even though it was awakened.
8. The code in lines 580-585 are now executed and an exception is thrown.
The problem is that this code will result in exceptions all the time on
heavily hit dynamic pages (with several connections being made in the page)
unless the maxConnections is raised unjustly. Also connectionWaitTimeout
specifies the amount of time a thread will wait, but doesn't consider the
fact that the above sequence might occur. In this case the awakened thread
may have only waited 1 second and caused an error, even if
connectionWaitTimeout is set to 10 seconds. I can see two solutions. One
solution is to revamp the synchronization to disallow new threads from
taking the lock before the awakened thread gets the lock. Or, the
connectionWaitTimeout property can be considered a TOTAL wait time and the
code can loop in that section. Something like the following may work:
long startTime = System.currentTimeMillis();
long remainingTime = connectionWaitTimeout;
boolean isEmpty = true;
while (remainingTime > 0 && isEmpty) {
try
{
wait( remainingTime );
}
catch (InterruptedException ignored)
{
// Don't care how we come out of the wait state.
}
if ( !pool.empty() ) isEmpty = false;
else remainingTime -= System.currentTimeMillis() - startTime;
}
This may not work. I haven't tested it, but the concept makes sense. I
will spend more time looking at the synchronization. At any rate, this is
the problem that we have seen while working with the package. It only shows
up on high database connection pages that are hit simultaneously. The only
fix has been raising the number of max connections, but this is considered a
poor fix. We will probably implement some type of loop for a total wait
time similar to what I listed, but we are still deciding. Could you please
give me some feedback? We may be WAY WAY off base here and missing a key
piece of the puzzle. That won't be the first time. =) I got both of your
e-mail addresses out of the source. I really appreciate any guidance that
you can give. Thank you again.
Terrence
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
