quartz-ra.rar bug?
I am running a clustered environment and need cron like functionality for some periodic maintenance we perform. I originally posted this under clustering but was recommended to try my hand here by Brian Stansberry.
The examples in the EJB3 tutorial for using the quartz-ra.rar work picture perfect. That is until I actually cluster the machine up. Then instead of one job executing for the cluster it executes on each instance.
Not a problem I discover the default Quartz implementation uses the Memory Job Store. I add a -D parameter so that it uses my own quartz.properties file which switches to a JDBC based Job Store.
Next problem, the data sources don't load before the .rar files so I have to move the file to the deploy.last directory. Now my resource name is deploy.last#quartz-ra ... inconvenient, but still workable.
Now the real problem. The JobStoreCMT file checks to make sure that if the JobDetail is marked as "volatile" the corresponding Trigger is also marked as "volatile." But, in the QuartzResourceAdapter.java the JobDetail is created with a volatility set to "true" during construction, but the CronTrigger doesn't supply that option at construction and the default setting is to have the volatility set to "false," which is never changed. A mismatch and a problem for me.
So why isn't there a volatile entry in the QuartzActivationSpec so we can set this in the deployment, or at least have both Trigger and JobDetail match? I am assuming this is a bug, but JIRA said to start here first. So here I am.
------ Followup from original posting
I added a volatile flag to the activation spec and it turns out Quartz tells you that if you are using a JDBC JobStore it is never volatile. So I then just set the JobDetail's volatility setting to false as well. Anyway with this change it appears (atleast with initial testing) to fix it.
