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.
Does Not Support Per-User Overrides.
