Bug 20549 - Avoid indexer race condition when moving item
Summary: Avoid indexer race condition when moving item
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-10 04:30 UTC by Alex Buckley
Modified: 2019-10-14 19:58 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:
Circulation function:


Attachments
WR 289187 - Avoid biblio index race condition after moving item (10.06 KB, patch)
2018-04-10 04:32 UTC, Alex Buckley
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Buckley 2018-04-10 04:30:39 UTC

    
Comment 1 Alex Buckley 2018-04-10 04:32:24 UTC
Created attachment 73899 [details] [review]
WR 289187 - Avoid biblio index race condition after moving item

The moveitem.pl script loops through a 2 value array containing "new"
and "old". The first loop value "new" is handed as an optional argument
to the MoveItemFromBiblio() function in C4/Items.pm. This updates the
biblios and only reindexes the new biblio.

If a 1 if returned from the call to MoveItemFromBilio() to moveitem.pl
then the loop iterates through the second value in the array "old" this
calls the MoveItemFromBiblio() function as well but this time the
aforementioned function only does one thing which is add the old biblio
to the zebraqueue.

Due to calling the ModItemFromBiblio() function twice from two different
iterations of the loop in moveitem.pl there is a 1 second gap between
the new biblio and old biblio being added to the zebraqueue table.

This reduces the chances of a race condition of the old biblio being
indexed before the new biblio.
Comment 2 Alex Buckley 2018-07-12 21:26:43 UTC
The bug that I wrote this patch for turned out to be a cataloging issue rather than a race condition in the execution of a reindex. 

The cataloging issue was causing Zebra to return two biblios when searching for the barcode of an item moved from one biblio to another. 

Therefore I am going to set this bug report to 'Resolved Fixed'.