[OPEN-ILS-DEV] Reshelving Complete

[Mike Rylander]

On Thu, Sep 17, 2009 at 10:24 PM, Bill Ott <bott at grpl.org> wrote:
> Mike Rylander wrote:
[snip]
> Here's some auditor data for an item that was in circulation for a few days,
> it was checked in and went from reshelving to available in about 36 minutes.
>  (current status is available, audit_times are desc)
>
>  id   | status |          audit_time
>  --------+--------+-------------------------------
> 381832 |      7 | 2009-09-17 13:00:01.43433-04
> 381832 |      1 | 2009-09-17 12:24:28.221189-04
> 381832 |      0 | 2009-09-11 13:13:07.690483-04
>

That's strange, for sure ... there must be something more going on
with that copy.  I'm sure there's a definable pattern, if this is
common-ish, though.

[snip]

>> The current definition centers on circulation completion.  It has the
>> two caveats you mention (transited items probably won't get the full
>> reshelving delay, and uncirculated item reshelving is based on
>> edit_date), but the central tenant seems correct.
>>
>
> Just to stay on track, it currently looks at create_date.
>

Indeed, pardon the thinko.

>
>> The first implication that comes to mind if we move to all-edit_date
>> is that we make it easy to extend the reshelving delay by making
>> changes to the copy unrelated to circulation or the concept of the
>> reshelving delay.  Today, those are all manual processes, but by
>> pinning what is currently meant to be "time since checkin" to a
>> generic "last time we touched the copy", we are opening ourselves up
>> to unintended consequences with automated processes down the road.  In
>> essence, any automated or batch process that deals with copies could
>> end up causing this unintended extension.
>>
>
> True...
>
>> Now, IMO, it's a question we should put to circulation managers, but
>> my vote is currently no on the option of moving to edit_date-based
>> reshelving.
>>
>> That said, I would be in favor of two alternate additions:  first,
>> adding another branch to the current query to take the most recent
>> transit of an item into account, if that transit ended /after/ the
>> most recent circulation; and, moving to UNION instead of UNION ALL to
>> improve the UPDATE performance.
>>
>> Thoughts on that counter-proposal?
>>
>
> Transits are certainly our largest issue.  Our volume and work flow puts
> items back to available much to soon in many cases.
>
> Performance of this query hasn't been an issue for us, but the examples
> above do confuse me.
>

We've seen one instance where, due to interactions between hold
targeting and the reshelving-complete query, a deadlock condition is
possible.  In that case, both the retargeting of the one hold and the
reshelving query are killed.  That's not really a problem for the
targetting query, as it will simply be retargeted again in 15 minutes,
but depending on how often and when the reshelver is run (and how long
it has to run -- how much work it has to do), it has the potential to
plug up the works in a pathological way.   Note that we've only seen
this in the most amazingly extreme case of massive (really, massive)
circulation and massive (no, really, MASSIVE) hold retargeting load
/and/ when you only run the reshelver once a day or less, and the
solution is as simple as "move the reshelving query away from the
nightly batch retargetting".

So, are their any circulation-manager-type folks out there that would
be willing to weigh in on this?  To summarize, the options on the
table are:

1) Tie reshelving-complete to the last edit time (effectively the
"last time we touched the copy") for copies in the Reshelving status
[non-circulation edits would extend the reshelving delay]
2) Extend the current behavior (checkin time OR create time for new,
uncirculated copies) to make it aware of transits and apply the delay
only after a post-circulation transit is complete [more complicated,
and possibly slower, reshelving query]

-- 
Mike Rylander
 | VP, Research and Design
 | Equinox Software, Inc. / The Evergreen Experts
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com