Seconds before c3p0‘s thread pool will try to interrupt an apparently hung task.
Rarely useful. Many
of c3p0‘s functions are not performed by client threads, but
asynchronously by an internal
thread pool. c3p0‘s asynchrony enhances client performance directly,
and minimizes the length of time that critical locks are held by
ensuring that slow jdbc operations are performed in non-lock-holding
threads. If, however, some of these tasks "hang", that
is they neither succeed nor fail with an Exception for a prolonged
period of time, c3p0‘s thread pool can become exhausted and
administrative tasks backed up. If the tasks are simply slow, the best
way to resolve the problem is to increase the number of threads,
via
numHelperThreads. But if tasks sometimes hang indefinitely, you can use this parameter to force a call to the task thread‘s
interrupt() method
if a task exceeds
a set time limit. [c3p0 will eventually recover from hung tasks anyway
by signalling an "APPARENT DEADLOCK" (you‘ll see it as a warning in the
logs), replacing the thread pool task threads, and interrupt()ing the
original threads. But letting the pool go into
APPARENT DEADLOCK and then recover means that for some periods, c3p0‘s
performance will be impaired. So if you‘re seeing these messages,
increasing
numHelperThreads and setting
maxAdministrativeTaskTime might
help.
maxAdministrativeTaskTime should be large enough that any
resonable attempt to acquire a Connection from the database, to test a
Connection, or two destroy a Connection, would be expected to succeed or
fail within the time set. Zero (the default)
means tasks are never interrupted, which is the best and safest policy
under most circumstances. If tasks are just slow, allocate more threads.
If tasks are hanging forever, try to figure out why, and maybe setting
maxAdministrativeTaskTime can help
in the meantime.
