Event-based JOb scheduling - quartz-scheduler

I have a requirement to generate certain reports as and when the DB is updated (say new alerts have been generated or new users have been created etc). I have MySQL DB triggers that get fired when the tables get updated and my question is can I schedule a job that gets executed whenever the DB trigger fires off?
This is Java Spring based application and I am considering Quartz but so far I haven't been able to figure out if Quartz can trigger jobs based on DB triggers. I have come across a 'jBatchEngine' that says "In contrast to time driven schedulers like Cron, jBatchEngine is event driven". Has anyone done such event-based job scheduling with Quartz or any other tools? Please advise !!
Thanks much !!!

Related

How to test quartz job

I'm using quartz framework to setup a schedule task in java.
eg: I hope the job will be triggered at 12:00 o'clock from 2022-01-25 to 2022-01-29.
is there any way that I can change the quartz's calendar to a specific date and time to make the schedule job can be triggered immediately?
if today is 2022-01-20, how can I mock current date and time in jvm, rather than bring up my spring boot service and wait, until that day...
thanks for your help.
The easiest way is probably using some of the GUI-based Quartz scheduler managers that let you connect to your Quartz scheduler manually execute arbitrary jobs through a GUI.
Here is an example of how to do that using QuartzDesk (I am biased here), but other tools may work similarly. Even the QuartzDesk Lite (free) edition lets you do that. No application code changes are required.

Can Quartz Scheduler Run jobs serially?

I'm looking into using Quartz Scheduler, and I was wondering if it was possible to schedule jobs not by time, but when another job finishes. So, when Job A is done, it starts Job B. When that's done, it starts Job C, etc.
Job A -> Job B -> Job C -> Job A... continuously.
Is this the right tool for the job? Or should I be looking into something else?
Check out JobChainingJobListener, built-in to Quartz (bold mine):
Keeps a collection of mappings of which Job to trigger after the completion of a given job. If this listener is notified of a job completing that has a mapping, then it will then attempt to trigger the follow-up job. This achieves "job chaining", or a "poor man's workflow".
That's right, you are looking for a process or workflow engine. Have a look at activiti or jbpm.
You may want to check the QuartzDesk project I have been involved in. QuartzDesk is a management and monitoring platform for Quartz-based apps and in version 2.0 we have added a new job chaining engine to the platform.
The engine allows you to orchestrate the execution of your jobs and there is no need to modify your application code in any way. Job chains can be dynamically updated through the QuartzDesk GUI without any disruption to your application.

Quartz job fires multiple times

I have a building block which sets up a Quartz job to send out emails every morning. The job is fired three times every morning instead of once. We have a hosted instance of Blackboard, which I am told runs on three virtual servers. I am guessing this is what is causing the problem, as the building block was previously working fine on a single server installation.
Does anyone have Quartz experience, or could suggest how one might prevent the job from firing multiple times?
Thanks,
You didn't describe in detail how your Quartz instance(s) are being instantiated and started, but be aware that undefined behavior will result if you run multiple Quartz instances against the same job store database at the same time, unless you enable clustering (see http://www.quartz-scheduler.org/docs/configuration/ConfigJDBCJobStoreClustering.html).
I guess I'm a little late responding to this, but we have a similar sort of scenario with our application. We have 4 servers running jobs, some of which can run on multiple servers concurrently, and some should only be run once. As Will's response said, you can look into the clustering features of Quartz.
Our approach was a bit different, as we had a home-grown solution in place before we switched to Quartz. Our jobs utilize a database table that store the cron triggers and other job information, and then "lock" the entry for a job so that none of the other servers can execute it. This keeps jobs from running multiple-times on the servers, and has been fairly effective so far.
Hope that helps.
I had the same issue before but I discovered that I was calling scheduler.scheduleJob(job, trigger); to update the job data while the job is running which is randomly triggered the job 5-6 times each run. I had to use the following to update the job data without updating the trigger scheduler.addJob(job, true);

Can I inject new jobs into the Quartz JDBCJobStore without clustering enabled?

I have several web-servers and need them to use Quartz. The clustering feature of Quartz would be ideal, but it requires that the servers clocks are in complete sync. They have a very scary warning about this:
Never run clustering on separate machines, unless their clocks are synchronized using some form of time-sync service (daemon) that runs very regularly (the clocks must be within a second of each other).
I cannot guarantee complete clock synchronization, so instead of using the clustering feature I was thinking to have a single Quartz instance (with a stand-by for fail-over). Having a single instance executing jobs is not a problem, but I still need all of the web servers to be able to schedule jobs.
Can I directly add jobs into the JDBCJobStore from the web servers, and will they be picked up by the (non-clustered) Quartz server? I would be doing this by creating schedule instances in the web servers to add jobs. These instances would never be started, just used to access the JobStore.
Wrote a test program that creates a "non-clustered" Quartz scheduler using the same JobStore as the "real" scheduler (also non-clustered), and schedules jobs. After a few seconds, these jobs do get executed, so it seems to work.
Update: I cross-posted this question to the Quartz forum, and got the answer that this should work. In a related question they state that
The jobs can be inserted into that database by another process by:
1- using the rmi features of quartz from another process, and using the quartz API
2- instantiating a scheduler within another process (e.g. webapp), also pointing it to the same database, but NOT start()ing that scheduler instace, and the using the quartz api to schedule jobs.

Windows Workflow: Persistence and Polling

I'm currently learning the WF framework, so bear with me; mostly I'm looking for where to start looking, not necessarily a direct answer. I just can't seem to figure out how to begin researching what I'd like in The Google.
Let's say I have a simple one-step workflow (much more complicated than that, but for simplicity's sake). This workflow needs to watch a certain record in the database to see when it changes. I don't have the capability to "push" via a trigger from the database when the row changes, so I need to poll for it every so often.
This workflow needs to be persisted to the database to be durable against restarts and whatnot as this is a long-running workflow. I'm trying to figure out the best way to get it to check every 3 minutes or so and also persist to the database. Do the persistence capabilities of the framework allow for that? It seems to be time-based. And since the workflow won't be reawakened by an external event, how does it reload from the database and check the same step it did previously again? Does it attempt the last unfulfilled activity automatically upon reloading?
Do "while" activities with a delay attached to it work at all, or can it be handled solely through the persistence services?
I'm not sure what you mean by "handled soley through persistence services"? Persistence refers only to the storing of an idle workflow.
You could have a Delay and a Code activity in a Sequence in a While loop. When in the Delay the workflow will go idle and may be persisted if necessary. However depending on how much state is needed when persisting the workflow and/or how many such workflows you would have running at any one time may mean that a leaner approach is necessary.
A leaner approach would be to externalise the DB watching and have some "DB watching" workflow service raise an event when the desired change has occured. This service would be added to Workflow runtime.
To that end you need a service contract which is defined by an Inteface with the [ExternalDataExchange] attribute. This interface in turn defines an event that the service will raise when the desired DB change is detected. It also defines a method that a Workflow can call to specify what what change this service should be looking for. The method should accept an instance GUID so that the requesting instance can be found when the DB change is detected.
In the workflow you use a CallExternalMethodActivity to call this services method. You then flow to a HandleExternalEventActivity which listen for the event. At this point the workflow will go idle and can be persisted. It will remain there until the service raises the event.