Delete/Add Quartz job and trigger in an outside (non-Quartz) transaction causes strange deadlock from time to time

[luciannistoruipath]

Version: 2.4.1.0

Expected behavior

We need to update Quartz (add or remove jobs) and other database tables in a single transaction while Quartz scheduler is working.
We need to do this in a single transaction in order to have our web app synchronized with Quartz - we add/edit/delete/enable-disable jobs from the web app.
We use the Quartz API to interact with Quartz.
We have one cron trigger per job.

Actual behavior

If we have at least one quartz job that triggers once every 1, 5 or 10 minutes and we try to disable it (remove all references of it from Quartz) and also mark it as disabled in our system, in the same transaction, while the scheduler is on, our application will block (or even throw timeout exception) from time to time.

From our investigation it seems to be a deadlock happening half in the database and half in Quartz. As soon as the scheduler trying to get next job to run times-out the enable/disable operation (adding or deleting Quartz jobs) completes fine.
This doesn't happen every time but still happens often enough to be an issue (once every 4 attempts).

Steps to reproduce

If we add the delete or add code in the same transaction as our other dbupdates (related to the scheduled jobs).
The solution we found so far is to do the Quartz operations outside of our transaction but that is not the desired behavior - we need them to be transactional.
Is there anything to know/to do, in order to use Quartz API inside our own transaction?
Is JobStoreCMT an option, and if yes, how can we configure it? Do you have an example for it?
This reproduces both in clustered and non-clustered environment.
We host Quartz in the same database as our production database.

Thank you for your support.

[lahma]

First of all, I don't recommend fiddling with Quartz data outside of the API. Using scheduler with ZeroSizeThreadPool and not starting it is a nice way to do updates against Quartz tables in maintenance mode.

If I understand correctly you are trying to have double bookkeeping by updating scheduling data in your own tables and Quartz's. Ideally you would just Quartz's tables to inform the status of the of the trigger/job.

I guess the real problem here is that you would like do issue update to two tables instead of one. That could be achieved by overriding StdAdoDelegate method in a way that you let the base call go through and then issue more command, these would share the transaction. that is provided to the delegate method. However there would be a lot methods to synchronize.

These are my thought, hope that I understood the description of your problem well enough.

[lahma]

Closing due to low activity.