Long-frozen holds skew hold queue position calculation

Bug #1744341 reported by Bill Erickson on 2018-01-19
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
Low
Unassigned

Bug Description

Evergreen 3.0 / affects all versions

When a hold is frozen, its target state is locked into place until it is unfrozen and retargeted. Any copy maps that link to copies which are deleted or made otherwise unholdable over time will remain as long as the hold is frozen. This adds bulk to the hold copy map table and leads to bogus queue positions, since copy maps for all holds are included in the queue position calculation.

Note this does not affect hold capture.

I propose a --retarget-frozen option for the hold targeter so these holds may be forcibly retargeted to refresh their hold copy maps at the users's discretion.

Jason Stephenson (jstephenson) wrote :

Bill, I like the idea, but I have a question:

Is there any reason to automatically retarget frozen holds? That is, are you concerned about performance or have other reasons for adding an option to retarget frozen holds and not just do it as part of the ordinary retargeting process?

Bill Erickson (berick) wrote :

Jason, my only concern was requiring the hold targeter run longer, particularly since frozen holds don't *need* to be constantly retargeted. If the consensus is it's worth it to avoid adding a new targeter option, I have no objections to always retargeting frozen holds.

Bill Erickson (berick) wrote :
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.1-beta
assignee: Bill Erickson (berick) → nobody
status: In Progress → New
Changed in evergreen:
milestone: 3.1-beta → 3.1-rc
Changed in evergreen:
milestone: 3.1-rc → 3.next
Michele Morgan (mmorgan) wrote :

Here's another question related to this bug. Should suspended holds have copy maps at all?

I have a long frozen hold with 68 entries in the hold_copy_map.

I place a new hold on the same record for another patron, it gets 22 entries in the hold_copy_map. I then suspend the hold, the 22 entries in the hold_copy_map remain, but will get stale as the hold remains frozen and time passes.

I place a new hold on the same record for another patron and suspend it at the time of placement, the hold gets 0 entries in the hold_copy_map.

When I activate these three holds, they get retargeted, so each hold now has 22 entries in the hold_copy map.

Since a suspended hold will be retargeted when it's activated, regenerating the copy map, what's the advantage of having copy maps for frozen holds at all?

Bill Erickson (berick) wrote :

Michele, one reason we retain the copy maps for frozen holds is the maps are used to calculate hold queue position. When the maps don't exist, the holds are ignored when calculating queue positions for holds in the same queue.

Arguably it's a bug that holds suspended at placement time have no copy maps.

Related to this, I'm considering opening a new LP to change (or offer an alternative to) how we calculate the queue position. The hold copy map table is large with a lot of turn-over, so querying the table is not always fast.

As of EG 2.12, "reporter.hold_request_record" is a proper database table that's quick to query. This table can be used to calculate queue positions if you define the hold queue position as all holds (across all types) that ultimately target the same bib record. It changes the meaning a bit, but the exact values don't mean as much as how they change over time. We've been using it locally to great effect.

Dan Wells (dbw2) on 2019-02-06
Changed in evergreen:
milestone: 3.next → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers