> I've created a very basic service implementation (which I suspect
> might be a useful thing to have included in the distribution?) based
There's a JIRA issue about this: http://jira.opensymphony.com/browse/QRTZNET-40
. I think a proper way
to handle is to add examples of source code how to handle this. Thanks
for you example.
> Should I run a program once that adds the jobs to the database,
> and just leave them in there? Should I use some kind of config file?
> Should I have a method that adds them when the scheduler service
> starts? How would this work in a farm?
The big difference when using DB based job store is just what creates
the confusion, initializing the job store state. There are two ways to
handle this: programmatic way and via configuration. The configuration
way is unfortunately still a job in progress (XML based configuration
of job similar to Java Quartz). The XML way would probably the way I
would go when it's finished.
But for the time being, the general instruction I would give is that
for "static" scheduling that should always exist, you should just use
the API to check whether triggers, calendars, jobs etc already exist
or not or just add them with replaceExisting = true when applicable.
Of course replacing is always redundant if you can determine whether
it's already scheduled (but again you need to replace when timing has
changed). If you look at the source of Java Quartz's
JobSchedulingDataProcessor you might get some hints.
In a farm situation there could be a race condition when setting up
the store but of course DB handles the locking etc. The scheduler
polls for next triggers and jobs so data will by synchronized to other
nodes of cluster.