Currently, a job enqueued first will run first regardless of the order of the due_at, which could, given enough work allow a single job to run multiple times (in the case of retries) before another job that was enqueued originally after, but due before the retried jobs.
This PR is complicated by the need to again change the locking index to retain performance levels on the job lock query. The DB upgrade is not required to function, but there may be performance degradation without it.
Currently, a job enqueued first will run first regardless of the order of the due_at, which could, given enough work allow a single job to run multiple times (in the case of retries) before another job that was enqueued originally after, but due before the retried jobs.
This PR is complicated by the need to again change the locking index to retain performance levels on the job lock query. The DB upgrade is not required to function, but there may be performance degradation without it.
Resolves #86