+1 Anytime we've reached this, there is a major problem in code or configuration. A notification is better than a 'hang'. > -----Original Message----- > From: Paul O'Leary [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 15, 2000 1:38 PM > To: [EMAIL PROTECTED] > Cc: Turbine > Subject: [Proposal] lRE: standalone connection pool bug? > > > Daniel, > > I don't think the thread code in ConnectionPool actually 'solves' this > problem, although it does address it. Looks like that code checks the > number of attempts and *will* wake up and release waiting > threads but it > solves the lack-of-connections problem by forceably shutting > down all active > connections...? This seems like it will cause errors in current, > unsuspecting sessions that assume their connections are valid. > > Seems strange but this resource managing stuff is a huge > issue and becomes > almost a little philisophical with a lot of people. > > Here's my take: the wait's there for a good reason. If > sessions manage the > cache correctly by grabbing their connections, using them and > then returning > them to the cache in a timely manner then the wait will > probably work well; > when there's an occasional cache 'miss' the thread will > pause, wait for a > connection to come back, grab it, go on it's merry way. > Problems come only > when the cache is not 'used correctly', that is connections are not > returned. The case you describe where there's more threads > than connections > *should* work correctly as long as the connections are > returned to the cache > after they're used. > > I'm droning on here. Here's my proposition, something of a > best-of-both > worlds solution that I've applied over and over before: keep > the wait but > assign a timeout to it, 5 or 10 seconds should do it. When a > thread wakes > up from the wait it can tell whether it woke up normally or > timed out. If > it woke up normally, there should be a connection ready for > it. Away it > goes. If it timed out then there's some problem in the > system, most likely > bad code not returning connections. Throw a big, ugly error > that tells the > user to complain to their incompetent system administrator :) > This should > handle both the steady state 'correct' case and the problem case. > > Anyway, I'll look at it right now and submit a patch. Guess > I coulda just > done that in the first place ;) > > PaulO. > > > [snip] > > > fyi, i talked to daniel in our apps-dev meeting today and > told him to > > uncomment the thread code that i had put at the bottom of one of the > > classes. it should help fix this problem. it was commented > cause i didn't > > have time to test it. > > I will be testing and deploying this code as my schedule allows (huge > deadline tomorrow). Until I put it in place (and I will), the > workaround for this "bug" is to simply increase the maximum number of > connections for your pools in the TurbineResources.properties file: > > # The number of database connections to cache per ConnectionPool > instance. > database.maxConnections=3 > > [snip] > > > > ------------------------------------------------------------ > To subscribe: [EMAIL PROTECTED] > To unsubscribe: [EMAIL PROTECTED] > Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> > Problems?: [EMAIL PROTECTED] > ----------------------------------------------------------------------- This message has been scanned for viruses with Trend Micro's Interscan VirusWall. ------------------------------------------------------------ To subscribe: [EMAIL PROTECTED] To unsubscribe: [EMAIL PROTECTED] Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/> Problems?: [EMAIL PROTECTED]
