Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Hi everyone,

in our application we observed a strange behaviour of quartz using the JDBC Jobstore during a database restart.
During this phase the quartz did several hundred reconnect attempts per second, although the db retry Interval was set to 15 s per default.

We debugged the Quartz code (version 2.2.1) and found out that
and exception is thrown in the method

protected <T> T executeInNonManagedTXLock(
String lockName,
TransactionCallback<T> txCallback, final TransactionValidator<T> txValidator) throws JobPersistenceException {
boolean transOwner = false;
Connection conn = null;
try {
if (lockName != null) {
// If we aren't using db locks, then delay getting DB connection
// until after acquiring the lock since it isn't needed.
if (getLockHandler().requiresConnection()) {
conn = getNonManagedTXConnection();
}

transOwner = getLockHandler().obtainLock(conn, lockName);
}

if (conn == null) {
conn = getNonManagedTXConnection(); <-- Exception is thrown
}

final T result = txCallback.execute(conn);
try {
commitConnection(conn);
} catch (JobPersistenceException e) {
rollbackConnection(conn);
if (txValidator == null || !retryExecuteInNonManagedTXLock(lockName, new TransactionCallback<Boolean>() {
@Override
public Boolean execute(Connection conn) throws JobPersistenceException {
return txValidator.validate(conn, result);
}

an exception is thrown during getNonManagedTXConnection() which causes to bypass the dbRetryInterval-Logic.

Is there any idea behind this behaviour or is it a gap?

In our case these caused heavy load on the database server and delay in the database server startup which is critical.

Many thanks and best regards,
Manfred