Quartz-Database Lock

Among them, Qrtz_locks is the quartz cluster implementation synchronization mechanism of the row lock table, its table structure is as follows:

Click (here) to collapse or open

1. --qrtz_locks table Structure
2. CREATE TABLE ' Qrtz_locks ' (
3. ' Lock_name ' varchar (+) not NULL,
4. PRIMARY KEY (' Lock_name ')
5. ) Engine=innodb DEFAULT Charset=utf8;
7. --qrtz_locks Records
8. +-----------------+
9. | Lock_name |
10. +-----------------+
11. | calendar_access |
12. | job_access |
13. | misfire_access |
14. | state_access |
15. | trigger_access |
16. +-----------------+

Note: This table structure has new fields in version 2.2 and is not considered here for the time being.
It can be seen that there are 5 records in Qrtz_locks, representing 5 locks, respectively, to achieve multiple quartz node to the job, Trigger, calendar Access synchronization control.
About the mechanism of row locks:
1, MySQL > Set autocommit=0; Set MySQL to not auto-commit first.
2. Select * from es_locks where lock_name = ' trigger_access ' for update; Thread one can lock this line up with a for update
3. Select * from es_locks where lock_name = ' trigger_access ' for update; Thread Cheng cannot get the lock through the for update, and threads wait.
4, commit; Thread one releases the lock through commit
5,///thread Two can access the data, the thread no longer waits.
So, with this mechanism, only one thread at a time can operate the lock-operate-release lock. If the operation takes too long, it will lead to the main thread waiting between the clusters.
A database row lock is a pessimistic lock that cannot be queried by other threads when the table is locked.
There are several ways to lock a database cluster in the source code:
1, the meaning of the Executeinnonmanagedtxlock method is to manage the transaction, not to let the container management transaction lock method.

Click (here) to collapse or open

1. Executeinnonmanagedtxlock (
2. String Lockname,
3. Transactioncallback<t> txcallback, final transactionvalidator<t> txvalidator)

The value of the three parameter lockname is the above-mentioned trigger_access, which indicates the type to be locked.
Txcallback is the method of locking after the callback.
Txvalidator is a validation method, which is generally null
The function performs a lock first, then calls back the method to be manipulated before unlocking.
Check the source code:

Click (here) to collapse or open

2. if (lockname! = null) {
4. If we aren ' t using DB locks, then delay getting DB connection
6. Until after acquiring the lock since it isn ' t needed.
8. if (Getlockhandler (). Requiresconnection ()) {
10. conn = Getnonmanagedtxconnection ();
12. }
16. Transowner = Getlockhandler (). Obtainlock (conn, lockname);
18. }
22. if (conn = = null) {
24. conn = Getnonmanagedtxconnection ();
26. }
30. Final T result = Txcallback.execute (conn);
32. try {
34. Commitconnection (conn);
36. } catch (Jobpersistenceexception e) {
38. Rollbackconnection (conn);
40. if (Txvalidator = = NULL | |!retryexecuteinnonmanagedtxlock (lockname, New transactioncallback<boolean> () {
42. @Override
44. Public Boolean Execute (Connection conn) throws Jobpersistenceexception {
46. Return Txvalidator.validate (conn, result);
48. }
50. })) {
52. Throw e;
54. }
56. }
60. Long sigtime = Clearandgetsignalschedulingchangeontxcompletion ();
62. if (sigtime! = null && sigtime >= 0) {
64. Signalschedulingchangeimmediately (Sigtime);
66. }
70. return result;
72. } catch (Jobpersistenceexception e) {
74. Rollbackconnection (conn);
76. Throw e;
77. } catch (RuntimeException e) {
    Rollbackconnection (conn);
    throw new Jobpersistenceexception ("Unexpected runtime exception:"
    + E.getmessage (), E);
    } finally {
    try {
    ReleaseLock (Lockname, Transowner);
    } finally {
    Cleanupconnection (conn);
    }
    }

2, if not through this callback method of lock, is generally:
Getlockhandler (). Obtainlock
Perform
Commitconnection (conn)
ReleaseLock
Cleanupconnection
Second, the source analysis lock

The current line of code locks only use the state_access and trigger_access two.

1, Trigger_access
First understand an article, through the source code to analyze how the quartz through the lock to achieve the cluster environment, trigger state consistency.
Http://www.360doc.com/content/14/0926/08/15077656_412418636.shtml
You can see that the action of the trigger is done primarily with the main thread stdschedulethread, whether it is to get a trigger within 30S that needs to be triggered, or to trigger the process. Select and UPDATE trigger tables
Will be locked first, then unlocked. If the database resources are more competitive, the lock will affect the performance. Consider placing task information in distributed memory, such as Redis, for processing. The database is only timed to count from the load data on Redis.
Reference: Quartz detailed 2:quartz to the fourth chapter 1th, section 2
Implementations are all in the Jobstoresupport class

Lock type
Lock method
Underlying database operations
Note

Executeinnonmanagedtxlock
Acquirenexttrigger
Selecttriggertoacquire
Selecttrigger
Selectjobdetail
Insertfiredtrigger
Search for trigger that require ignition
Select the trigger you want to perform to join the Fired_trigger table

For execution triggerfired
Selectjobdetail
Selectcalendar
Updatefiredtrigger
Triggerexists Updatetrigger
Ignition Trigger
Modifies the trigger state to an executable state.

Recoverjobs
Updatetriggerstatesfromotherstates
Hasmisfiredtriggersinstate Doupdateofmisfiredtrigger
Selecttriggersforrecoveringjobs
Selecttriggersinstate
Deletefiredtriggers
Re-execution in a non-clustered environment
The trigger of failed and misfired

Retryexecuteinnonmanagedtxlock
Releaseacquiredtrigger
Updatetriggerstatefromotherstate
Deletefiredtrigger
Re-release trigger to the initial state in case of exception.

Triggeredjobcomplete
Selecttriggerstatus
Removetrigger updatetriggerstate
Deletefiredtrigger
Triggers processing after the job task completes.

Obtainlock
Recovermisfiredjobs
Hasmisfiredtriggersinstate Doupdateofmisfiredtrigger
Re-executing misfired's trigger
can be executed at startup or periodically by the misfired thread.

Clusterrecover
Selectinstancesfiredtriggerrecords
Updatetriggerstatesforjobfromotherstate
Storetrigger
Deletefiredtriggers
Selectfiredtriggerrecords
Removetrigger
Deleteschedulerstate
The cluster has node faied, allowing the job to be re-executed.

Executeinlock
The database cluster is equivalent to
Executeinnonmanagedtxlock
Storejobandtrigger
Updatejobdetail Insertjobdetail
Triggerexists
Selectjobdetail
Updatetrigger Inserttrigger
Save job and Trigger configuration

Storejob
Save Job

Removejob
Delete Job

Removejobs
Bulk Delete Job

Removetriggers
Bulk Delete triggers

Storejobsandtriggers
Save job and multiple trigger configurations

Removetrigger
Delete Trigger

Replacetrigger
Replace Trigger

Storecalendar
Save timed date

Removecalendar
Delete a timed date

Clearallschedulingdata
Clear all timing data

Pausetrigger
Stop Trigger

Pausejob
Stop task

Pausejobs
Bulk Stop Task

Resumetrigger
Recovery triggers

Resumejob
Restore tasks

Resumejobs
Batch Recovery tasks

Pausetriggers
Bulk Stop Trigger

Resumetriggers
Batch recovery triggers

Pauseall
Stop all

Resumeall
Restore All

---
2, State_trigger
Implementations are all in the Jobstoresupport class

Lock type
Lock method
Underlying database operations
Note

Obtainlock
Docheckin
Clustercheckin
Determine cluster status
Lock cluster state with Lock_state_access first
Re-use Lock_trigger_access to restore cluster operation

---

Quartz-Database Lock