Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue after data recovering #26

Open
mouradchama opened this issue Feb 6, 2023 · 0 comments
Open

Issue after data recovering #26

mouradchama opened this issue Feb 6, 2023 · 0 comments

Comments

@mouradchama
Copy link

Hi,

I try to use Quartz.Net with RavenDb, I'm blocking the concurrent execution with the attribute (DisallowConcurrentExecution).

When the scheduler start the code start to recover the data from the data base (RavenJobStore.Util.cs, method : RecoverSchedulerData), if the trigger state is Acquired or Blocked we restore the default state which is Waiting.

                var queryResult = await session
                    .Query<Trigger>()
                    .Include(t => t.Scheduler) // pre-load scheduler
                    .Where(t =>
                        t.Scheduler == InstanceName && (t.State == InternalTriggerState.Acquired ||
                                                        t.State == InternalTriggerState.Blocked)
                    )
                    .ToListAsync(cancellationToken);
                foreach (var trigger in queryResult)
                {
                    var triggerToUpdate = await session.LoadAsync<Trigger>(trigger.Key, cancellationToken);
                    triggerToUpdate.State = InternalTriggerState.Waiting; //    <=== here
                }

There is a big issue with this approach. You will not the see the issue if you have a job with CRON expression, specially when the next trigger is not at the startup of your application.

If the trigger is at the startup and your start 2 instances at the same time, the first instance will trigger and lock the the state, but the second instance will restore the state (from Blocked to Wating) and trigger for a second time the job.

Is there any thing that we can do with this? why not simply removing this recovery step?

Thank you in avance.
Regards,
Mourad

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant