Platform, DevOps and Release Management (UXPROD-1814)

[UXPROD-3015] ACQ Mods - Prevent update conflicts (two automated processes acting on the same record) Created: 26/Mar/21  Updated: 06/Apr/22

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

Type: New Feature Priority: P3
Reporter: Dennis Bridges Assignee: Dennis Bridges
Resolution: Unresolved Votes: 0
Labels: Support, acq-dev-grooming, acq-morningglory-candidate, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-2798 Prevent update conflicts (two automat... Closed
Defines
is defined by MODINVOICE-274 Implementing optimistic locking for i... Open
is defined by MODINVOICE-233 Integration test check-invoice-and-in... Closed
Relates
relates to MODINVOICE-297 Spike: Optimistic Locking for Acquisi... Open
Epic Link: Platform, DevOps and Release Management
Development Team: Thunderjet
PO Rank: 60
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R2
Rank: TAMU (MVP Jan 2021): R3
Rank: U of AL (MVP Oct 2020): R2

 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.

  • TBD

User impact

  1. prevent collisions?
  2. 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.


 Comments   
Comment by Tom Wilson [ 13/Apr/21 ]

I'd like to suggest a couple of things: 1) optimistic locking needs to be implemented across the board in FOLIO, so let's make sure that it is implemented similarly across the board, i.e., not one way in order data and another in users and yet another in SRS; and 2) longer-term, the issue of having separate stores for the apps and in the UIs needs to be rethought. This is not a microservices issue, as some might suggest, this is an underlying design choice that is generating a large number of issues related to OL as well as synchronization. 

Comment by Ann-Marie Breaux (Inactive) [ 14/Apr/21 ]

Hi Tom Wilson: Dennis Bridges is out until next week. As far as I know, if any optimistic locking gets worked on in Juniper, at most it will be a POC for one module (most likely Inventory). But best for Jakub Skoczen to confirm. All of the POs for other modules have not yet created stories for this work until the POC is completed, and we have some received some recommendations on how to implement in our modules. I can confirm that this work is definitely not scheduled for R2/Juniper for Acquisitions or Data Import.

Comment by Marc Johnson [ 15/Apr/21 ]

Tom Wilson

the issue of having separate stores for the apps and in the UIs needs to be rethought.

What do you mean by having separate stores for the apps and the UIs?

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