Handling concurrent multithreading using the database's update lock mechanism

Before the company to do a timed task, the task itself logic difficult, but our production environment is 4 server cluster, test environment is also 2 server integration, then for the job will face a problem,

If your job is to run 2.30 hours a day, 4 servers will execute the job at the same time, and if you update the same data, dirty reads will occur. Dealing with this problem can be solved with the database update lock, because we know that the updated number of bars is returned after the update, so we use an indication state to indicate that a server is currently executing the job.

If the flag indicates that the default is n without job execution, the first server enters the job to update this to Y then the number of update bars will be returned to 1, and the other three machines will have an update number of 0, so if it is OK to judge, and then in the normal execution and exception code block is also The original is to change the Y to n code affixed:

    //N for the present no one executes y means already in execution if N can be changed to Y-proof that no one is currently performing. The default execution will change to n//change N to y if the number of modified bars is greater than 0 indicates success, no one        intUpdatedcount = Commsysparamdao.updateparamvaluebyparamkey (systemconstant.message_schedule_quartz_is_started, Systemconstant.no, Systemconstant.yes,NULL); Booleanisquartzstarted = (Updatedcount <= 0); if(isquartzstarted) {message= "Executemsgboardscheduleandremindjob: Already in execution, cannot be re-executed!" ";            Logger.info (message); returnmessage; }        

Note: This requires creating a configuration parameter table with ID key value sufficient to

Handling concurrent multithreading using the database's update lock mechanism