Details
-
Type:
New Feature
-
Status: Closed (View Workflow)
-
Priority:
P3
-
Resolution: Duplicate
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:
-
Template:
-
Epic Link:
-
Development Team:Core: Platform
-
Calculated Total Rank:
-
Rank: Chicago (MVP Sum 2020):R1
-
Rank: Cornell (Full Sum 2021):R1
-
Rank: Duke (Full Sum 2021):R1
-
Rank: 5Colleges (Full Jul 2021):R1
-
Rank: FLO (MVP Sum 2020):R1
-
Rank: GBV (MVP Sum 2020):R1
-
Rank: Leipzig (Full TBD):R1
-
Rank: Mainz (Full TBD):R1
-
Rank: MO State (MVP June 2020):R2
-
Rank: TAMU (MVP Jan 2021):R1
-
Rank: U of AL (MVP Oct 2020):R1
Description
Problem statement
In FOLIO, most storage modules follow the "last writer wins" strategy for handling record updates. From the UI perspective this may lead to a situation when a stale record (older version of a give record) previously loaded into the UI may override a more recent version on the server. Hence relevant updates may get lost in the process and the user is not made aware of what has happened.
This situation can happen when multiple data imports are happening at the same time (or data import and a user acting on the same record at the same time) and can affect many records at the same time. Cleanup can then be very time-consuming and confusing.
Proposed solution
From the storage and API perspective, optimistic locking is the proposed strategy to handle conflicts. Handling of updates in FOLIO should rely on more explicit semantics, both in the storage (backend) APIs and the way it is communicated to the user through the UI.
Use cases:
Two automated processes acting on the same record.
- Checkout happening and updating status on an item record at the same time as import updating the item
- Data import happening at 2 libraries within the same tenant, affecting the same record (e.g. 5 Colleges processing new cataloging records)
User impact
- prevent collisions?
- notify the user when they happen and offer them a choice? Something like, "Sorry AgentB has already updated the record and your working copy might not be up-to-date? Would you like to:" (a) Update anyway (b) Reload.
TestRail: Results
Attachments
Issue Links
- defines
-
UXPROD-3058 Optimistic Locking
-
- In progress
-
- is blocked by
-
RMB-719 SPIKE: design protocol and implementation for optimistic locking
-
- Closed
-
-
UXPROD-1752 Prevent update conflicts (via optimistic locking): platform support for detection
-
- Closed
-
- is cloned by
-
UXPROD-3015 ACQ Mods - Prevent update conflicts (two automated processes acting on the same record)
-
- In Refinement
-
- is defined by
-
MODINVSTOR-713 Enable support for optimistic locking (failOnConflict) in instances/holdings/items (part1)
-
- Closed
-
-
RMB-719 SPIKE: design protocol and implementation for optimistic locking
-
- Closed
-
-
RMB-727 Implement support for optimistic locking
-
- Closed
-
-
UIIN-1245 Implement optimistic locking in Inventory
-
- Closed
-
- relates to
-
DEBT-1 No optimistic locking/update conflict resolution
-
- In progress
-
-
RMB-388 PostgresClient.getById with transaction, with "SELECT … FOR UPDATE"
-
- Closed
-
-
RMB-688 PATCH to update only some JSONB properties
-
- Open
-
-
UIIN-730 Error message when item has been deleted from another window
-
- Blocked
-
-
UIREQ-344 Deleting already-deleted request causes ungraceful error
-
- Open
-
-
UXPROD-2796 Prevent update conflicts when doing manual edits (User A and User B)
-
- Closed
-
-
UXPROD-2797 Prevent update conflicts (1 user and system trying to act on the same record)
-
- Closed
-
-
FOLIO-2027 Data Problems from Front-End Record Caching
-
- Open
-
-
MODINVSTOR-516 Cannot safely update holdings and items concurrently for any given instance
-
- Closed
-
-
UXPROD-3089 Inventory. Implementing Optimistic Locking
-
- Closed
-