Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

We have a lock contention of more than 50,000 executions on qrtz_locks table. quartz 2.1.7 version is being used.

Application is running on 3 nodes in a clustered environment.

34 jobs are being executed every 6 seconds, means total number of times
the jobs were triggered in 1 hour in each node is 20400. so for 3 nodes the following query would be executed morethan 60000.

SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME = 'Scheduler1' AND LOCK_NAME = :1 FOR UPDATE

It is impacting the performance of the DB. How can i reduce the lock contention ? Can i have multiple schedulers with in a cluster ?

current qrtz_locks table has following entries ,

TRIGGER_ACCESS
STATE_ACCESS

Any other entries would reduce the lock contention ?

We observe the same behavior on our J2EE application [Quartz-2_1_7].

The report (time UTC)/(waiting time) is huge :
we are waiting 4.646sec to 3.1seconds of processing.

The guilty :
SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME = 'Scheduler' AND LOCK_NAME = :1 FOR UPDATE

Like for rssviswa, it is impacting the performance of our DB (Oracle 11g).
that pass 99.8% of the time to wait.

So, How can i reduce this lock contention ?

Best regards,

We are using Quartz version 2.2.1, running on Weblogic 10.3.4 and Oracle 11g. The WL cluster consists of 2 nodes.

There runs 1 job every second and also have lock contention on the Quartz table.

Hopefully there is an solution for this problem?

The following configuration is used:

#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.wrapJobExecutionInUserTransaction = false
org.quartz.scheduler.instanceName = jAMC-Scheduler
org.quartz.scheduler.instanceId = AUTO
org.quartz.scheduler.rmi.export = false
org.quartz.scheduler.rmi.proxy = false
org.quartz.scheduler.skipUpdateCheck = true
org.quartz.scheduler.threadsInheritContextClassLoaderOfInitializer = true
org.quartz.scheduler.threadName = jAMC-SchedulerThread
org.quartz.scheduler.jmx.export=true

#============================================================================
# Configure ThreadPool
#============================================================================

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 10
org.quartz.threadPool.threadPriority = 5
org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true

#============================================================================
# Configure JobStore
#============================================================================

org.quartz.jobStore.misfireThreshold = 500
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.tablePrefix = QRTZ_
org.quartz.jobStore.dataSource = XADS
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.clusterCheckinInterval = 5000
org.quartz.jobStore.useProperties = true
org.quartz.jobStore.dontSetAutoCommitFalse = false
org.quartz.jobStore.maxMisfiresToHandleAtATime = 10

#============================================================================
# Configure Datasources
#============================================================================

org.quartz.dataSource.XADS.jndiURL = ODBDS
org.quartz.dataSource.XADS.maxConnections = 10
org.quartz.dataSource.XADS.validationQuery=select 0 from dual

I have exactly the same problem .....

SELECT * FROM QRTZ_LOCKS WHERE SCHED_NAME = :"SYS_B_0" AND LOCK_NAME = :1 FOR UPDA TE

runs 68,557 times and created row lock contention....

Is there a way to avoid this ...

Thanks !