[UXPROD-2797] Prevent update conflicts (1 user and system trying to act on the same record) - FOLIO Issue Tracker

XML

Word

Printable

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:

UXPROD features
Epic Link:
Platform, DevOps and Release Management
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):
R2
Rank: GBV (MVP Sum 2020):
R1
Rank: Leipzig (Full TBD):
R1
Rank: Mainz (Full TBD):
R1
Rank: MO State (MVP June 2020):
R1
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.

Proposed solution
From the storage and API perspective, optimistic locking is the proposed strategy to handle conflicts: (~~UXPROD-1752~~). 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
1 user and system trying to act on the same record, either individual records or batch

User A editing a user and system batch process is updating lots of users
User A editing an instance/holding/item and data import updating the same record (consider the DI redesign that is taking place now)
User A editing an item and checkout trying to update the item status
User A editing an item and bulk renewal trying to update the item
User A editing a budget and system applying a transaction to that budget at the same time
User A editing an instance/holdings/item after data import ran in Preview mode but before the data import changes were committed
User A editing a request while the request is being expired (request expiration date or hold shelf expiration date) - rare

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 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

Closed

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

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-2798 Prevent update conflicts (two automated processes acting on the same record)

Closed

UXPROD-3089 Inventory. Implementing Optimistic Locking

Closed

(2 is defined by , 9 relates to)

Activity

People

Assignee:: Jakub Skoczen

Reporter:: Charlotte Whitt

Votes:: 0 Vote for this issue

Watchers:: 21 Start watching this issue

Dates

Created:: 02/Nov/20 8:31 AM

Updated:: 27/Apr/22 9:29 AM

Resolved:: 14/Jun/21 8:27 PM

Prevent update conflicts (1 user and system trying to act on the same record)