Is there a reason for waitCount to be static? john mcnally
Byron Foster wrote: > > Terry explains the issue well so take a look at his message for a > description of the problem. > > This patch fixes the problem by keeping track of the number of threads > that are in the wait state. If a new thread calls the > getInternalPooledConnection method and the wait count is not zero then > the calling thread drops into the wait state. This allows a potential > thread "awakened" from the wait state by a notify call to acquire the > synchronize lock and obtain the connection. It also acts in a "fair" > way since if there are existing threads in a wait state when a thread > calls the get connection method then the thread will also go into the > wait state, essentially getting in the back of the line. > > Byron > > On Tue, 2001-11-27 at 12:50, Terry August wrote: > > > > 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: > > > > ------------------------------------------------------------------------ > Name: con_pool.patch.txt > con_pool.patch.txt Type: Plain Text (text/plain) > Encoding: quoted-printable > > ------------------------------------------------------------------------ > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
