[Logo] Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Messages posted by: schmidma  XML
Profile for schmidma -> Messages posted by schmidma [1]
Author Message
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 {
} catch (JobPersistenceException e) {
if (txValidator == null || !retryExecuteInNonManagedTXLock(lockName, new TransactionCallback<Boolean>() {
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,

Profile for schmidma -> Messages posted by schmidma [1]
Go to:   
Powered by JForum 2.1.7 © JForum Team