https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43989 Bug ID: 43989 Summary: Concurrent real-time holds queue updates can deadlock and leave holds off the Holds queue Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs@lists.koha-community.org Reporter: sam.young@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org CC: gmcharlt@gmail.com, lisette@bywatersolutions.com, tomascohen@gmail.com Target Milestone: --- With RealTimeHoldsQueue enabled, a single action (e.g. a check-in) enqueues several update_holds_queue_for_biblios jobs for the same biblio (Koha::Item->store, the SIP/circ check-in code, hold changes). When the worker runs these in parallel, update_queue_for_biblio deletes and re-inserts the same tmp_holdsqueue/hold_fill_targets rows from two transactions at once. One fails with "Deadlock found when trying to get lock", BatchUpdateBiblioHoldsQueue rolls it back and records an error, and it is never retried. If the failed update was the one carrying the newer state (e.g. the item is now available), the hold stays off the Holds queue until something else touches the biblio. Holds to pull still shows it, because it works out the list when the page is loaded. Since build_holds_queue.pl exits without --force while RealTimeHoldsQueue is on, nothing catches these misses unless the cron is run with --force. To reproduce: in two processes, begin a transaction and call update_queue_for_biblio( { biblio_id => $id, delete => 1 } ) for a biblio with a pending hold and an available item, with a short sleep before CreatePicklistFromItemMap. The second process dies with a deadlock. Seen in production at a ByWater partner: holds on Holds to pull were missing from the Holds queue for months. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.