Platform, DevOps and Release Management (UXPROD-1814)

[UXPROD-2797] Prevent update conflicts (1 user and system trying to act on the same record) Created: 02/Nov/20  Updated: 27/Apr/22  Resolved: 14/Jun/21

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Platform, DevOps and Release Management

Type: New Feature Priority: P3
Reporter: Charlotte Whitt Assignee: Jakub Skoczen
Resolution: Duplicate Votes: 0
Labels: Support, platform-backlog, round_iv
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Blocks
is blocked by RMB-719 SPIKE: design protocol and implementa... Closed
is blocked by UXPROD-1752 Prevent update conflicts (via optimis... Closed
Defines
defines UXPROD-3058 Optimistic Locking In Progress
is defined by MODINVSTOR-713 Enable support for optimistic locking... Closed
is defined by RMB-719 SPIKE: design protocol and implementa... Closed
is defined by RMB-727 Implement support for optimistic locking Closed
is defined by UIIN-1245 Implement optimistic locking in Inven... Closed
Relates
relates to RMB-688 PATCH to update only some JSONB prope... Open
relates to DEBT-1 No optimistic locking/update conflict... Closed
relates to RMB-388 PostgresClient.getById with transacti... Closed
relates to UIREQ-344 Deleting already-deleted request caus... Closed
relates to UIIN-730 Error message when item has been dele... Blocked
relates to FOLIO-2027 Data Problems from Front-End Record C... Open
relates to MODINVSTOR-516 Cannot safely update holdings and ite... Closed
relates to UXPROD-3089 Inventory. Implementing Optimistic Lo... Closed
relates to UXPROD-2798 Prevent update conflicts (two automat... Closed
Epic Link: Platform, DevOps and Release Management
Development Team: Core: Platform
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 Closed ). 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


 Comments   
Comment by Khalilah Gambrell [ 14/Jun/21 ]

After talking with Jakub Skoczen, I have decided to close this feature. UXPROD-1752 Closed will/have addressed the work to prevent conflicts. Each app/dev team will create a feature(s) to implement the work noted with UXPROD-1752 Closed

UXPROD-2994 Open outlines the work to implement optimistic locking (OL) for the Inventory app. It is the first app to implement OL and will serve as the pattern for dev teams to apply OL to their apps/systems.

Generated at Fri Feb 09 00:26:55 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.