Details
-
Story
-
Status: Closed (View Workflow)
-
P1
-
Resolution: Done
-
None
-
None
-
None
Description
Reliability of the system, data consistency
How to handle concurrent (conflicting) updates to records?
UXPROD-1752 not in MVP List (row 499). Lobby for this to be included in Q1 or Q2 of 2020. It's important but may not outweigh other functional features/work. May implement as a "client opt-in" manner.
Update July 17 2019: No activity to date. Discussion about deprioritizing since some have indicated it's not abnormal or not a big problem. Others, though, feel it's an expectation when coming from a traditional client-server SQL-based solution. Decided to leave a 'High' for several reasons.
Attachments
Issue Links
- relates to
-
FOLIO-2028 SPIKE: how to handle update conflicts?
-
- Closed
-
-
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
-
-
UXPROD-1752 Prevent update conflicts (via optimistic locking): platform support for detection
-
- Closed
-
-
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
-
-
UXPROD-2798 Prevent update conflicts (two automated processes acting on the same record)
-
- Closed
-