quartz in cluster with same instanceId

[acavalli]

My problem is as follows:

I have a service method doIt() which simply puts a message on a JMS queue for each user having a certain property X, which is determined via a dB lookup. doIt() is called at a regular intervals.

To achieve this aim in a non-cluster I just use MethodInvokingJobDetailFactoryBean with a cronTrigger and RAMJobStore and all is fine.

When moving to a cluster and using JobStoreTX I have the following issues: (1) JobDetails created by MethodInvokingJobDetailFactoryBean are non-serializable; (2) no way to have each instance in cluster have same instanceId such that only one cluster succeeds in sending the message -- dB corruption issues aplenty.

(1) is solvable by writing my own Job, but (2) is more problematic. Playing around with the quartz examples in their downloadable I realised that clustering support is there to support fail-over, not what I'm wanting to do.

To solve (2) I was thinking of writing a line in doIt() like

if (aquireDbLock()) { 
   // ... do Work  
} 
// else do nothing as assume other cluster got there first

but writing aquireDbLock() involves setting up a custom lock table etc that will involve its own issues/maintainance moving forward.

Is there a way of using quartz or some other technology to achieve my aim? One way is just not to deploy the code to the cluster, just one box instead but (a) boss man doesn't like that cause it'll involve a seperate release procedure ; and (b) no fail-over support in that solution.

Cheers,

Anthony.

[j2eeguru]

What is the DB you are using?

If Oracle, I do 'select ... for update NOWAIT' to lock all rows with property x and some other field which will be updated once the the message is successfully put on the queue. That way, only one server instance in the cluster can process the job at one time. You would not need to maintain a lock table for that solution.

[acavalli]

I am using Oracle 10g, so yes the select for update clause to lock rows in some mutex lock table would work.

Another alternative maybe that since we are using Weblogic 8.1 as the app server if I package this as a separate ear then might be able to target only to one cluster in some weblogic xml config in order to avoid any special release script.

Mainly wanted to sanity check myself in the sense no sort of quartz configuration solves this problem. Would be good to read any quartz guys thoughts on this.

[juldsc]

Well, what you seem to be looking for is Stateful Jobs. Stateful jobs will never be executed at the same time even in a clusterized quartz deployment. Note that the ending state of the job is not mandatory. We uses it and it works perfectly.

[sbayer]

Well, what you seem to be looking for is Stateful Jobs. Stateful jobs will never be executed at the same time even in a clusterized quartz deployment. Note that the ending state of the job is not mandatory. We uses it and it works perfectly.

Is this true when using a cluster of WebLogic nodes (i.e., when not clustering Quartz alone)?