Bug 35995 - Real time holds queue jobs for the same record should run in serial, never parallel
Summary: Real time holds queue jobs for the same record should run in serial, never pa...
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Hold requests (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-02-05 15:49 UTC by Kyle M Hall
Modified: 2024-02-05 15:49 UTC (History)
1 user (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kyle M Hall 2024-02-05 15:49:12 UTC
As described in bug 34596 there are times when multiple jobs to rebuild the holds queue for a single job will run where the first job as the last to execute ( or at least the last to finish ).

We need to force these jobs to run in serial, and only the newest job for a given record *needs* to run, older jobs can exit early.

To this end, I propose a "holds queue job lock" table. The table will have rows for the record id, and the timestamp of job initiation.

When a job begins processing, it will attempt to insert a row into this table.
If that insert succeeds, the job will process then remove the lock from the table.

If the insert fails, it means another job has already written a lock. 
The blocked job can then read the row in the table.
If the queued time for the job that got the lock is newer than the time queued for the blocked job that is checking it, that job can exit as it is obsolete.
If the queue time for the job that got the lock is older than the time queue for the blocked job, that job needs to reinsert itself into the job queue before exiting so it may try again in the future.