Hi there. We are planning to use Quartz as a backend general job
scheduler.

There will be lots of jobs that run immediately (created by our
webservers in response to user actions), and a few jobs that happen on
regular schedules (for batch processing).

I've created a very basic service implementation (which I suspect
might be a useful thing to have included in the distribution?) based
on reading the docs. I have managed to test it with run immediately
jobs, but I'm a bit confused about how I should set up the scheduled
jobs. 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?

thanks

harry

My scheduler class - note that
Common.Properties.QuartzSchedulerProperties is a reference to our
Common.dll where we keep constants.
___________________________________
        public partial class Service : ServiceBase
        {
                ISchedulerFactory schedulerFactory;
                IScheduler scheduler;
                public Service()
                {
                        InitializeComponent();
                        schedulerFactory = new
StdSchedulerFactory(Common.Properties.QuartzSchedulerProperties);
                        scheduler = schedulerFactory.GetScheduler();
                }

                protected override void OnStart(string[] args)
                {
                        scheduler.Start();
                }

                protected override void OnStop()
                {
                        scheduler.Shutdown();
                }
        }

Hi Harry,

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.

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.

Cheers,

-Marko