+-- On Feb 26, Scott Goodwin said:
> Can someone briefly explain to me why, once you have allocated handles from
> a database pool, you cannot allocate more from the same pool until you
> release all the ones you already have from that pool? Is it a race
> condition, a performance trade-off or something else?
It's to avoid deadlock. Let's say you have a pool named "mypool" with 2
hnadles, and you have a proc "deadlock":
proc deadlock {} {
# Step 1.
set db1 [ns_db gethandle mypool]
# Step 2.
ns_sleep 1
# Step 3.
set db2 [ns_db gethandle mypool]
}
Suppose both handles are available in mypool, and thread T1 calls
deadlock. It gets the first handle from mypool and then sleeps for one
second. Suppose that during that second, thread T2 calls deadlock. T2
will grab the second handle from mypool and sleep. Then T1 wakes up and
tries to grab another handle from mypool. There are none left, so T1
blocks. Then T2 wakes up and tries to grab another handle from mypool;
it also blocks. The threads are deadlocked, because each is waiting
for the resource that the other thread owns.
You could try to implement a deadlock-detection scheme in gethandle, but
it would be difficult or impossible to make it work in all cases. For
example, what if T2 isn't waiting for a handle owned by T1, but instead
is waiting for a mutex locked by T1? The simplest solution is to require
a thread to acquire all of its handles (from any one pool) at once. This
prevents the most likely cause of deadlock. You can still deadlock on
mutexes if you want :^), but using mutexes is more advanced than using
database handles.
In ACS, they worked around this restriction by having several pools, and
always grabbing a handle from pool "main" first, then from "subquery",
then from "log". (The names are anachronistic.) This is deadlock
avoidance by resource ordering. If you want to know more, go to the
library and find a book about concurrent programming.
