acavalli
Feb 3rd, 2005, 04:51 AM
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.
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.