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]
