on 9/15/2000 11:38 AM, "Paul O'Leary" <[EMAIL PROTECTED]> wrote:
> 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.
Right...that is why I left it commented out. That code is probably at least
a year old now.
> 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.
Right. The only problem we are trying to solve is when the cache isn't used
correctly. Daniel, are you 100% sure you are returning ALL connections in a
finally statement? Your problem smells of a connection leak more than
anything.
> 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.
Sounds ok, but still doesn't entirely solve a problem where a single
connection might freeze up for a long period of time for some unknown
reason.
> Anyway, I'll look at it right now and submit a patch. Guess I coulda just
> done that in the first place ;)
:-)
-jon
--
http://scarab.tigris.org/ | http://noodle.tigris.org/
http://java.apache.org/ | http://java.apache.org/turbine/
http://www.working-dogs.com/ | http://jakarta.apache.org/velocity/
http://www.collab.net/ | http://www.sourcexchange.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
