Uploaded image for project: 'UX Product'
  1. UX Product
  2. UXPROD-2798

Prevent update conflicts (two automated processes acting on the same record)

    XMLWordPrintable

Details

    • Core: Platform
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R1
    • R2
    • R1
    • 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

      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.

      TestRail: Results

        Attachments

          Issue Links

            defines

            Umbrella - UXPROD-3058 Optimistic Locking

            • TBD - To be determined
            • In progress
            is blocked by

            Task - A task that needs to be done. RMB-719 SPIKE: design protocol and implementation for optimistic locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests UXPROD-1752 Prevent update conflicts (via optimistic locking): platform support for detection

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed
            is cloned by

            New Feature - New feature requests UXPROD-3015 ACQ Mods - Prevent update conflicts (two automated processes acting on the same record)

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • In Refinement
            is defined by

            New Feature - New feature requests MODINVSTOR-713 Enable support for optimistic locking (failOnConflict) in instances/holdings/items (part1)

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Task - A task that needs to be done. RMB-719 SPIKE: design protocol and implementation for optimistic locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests RMB-727 Implement support for optimistic locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. UIIN-1245 Implement optimistic locking in Inventory

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed
            relates to

            Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DEBT-1 No optimistic locking/update conflict resolution

            • P1 - highest priority item, drop everything else before this is resolved, reserved for critical bugfixes
            • Closed

            New Feature - New feature requests RMB-388 PostgresClient.getById with transaction, with "SELECT … FOR UPDATE"

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests RMB-688 PATCH to update only some JSONB properties

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Open

            Tech Debt - UIIN-730 Error message when item has been deleted from another window

            • P4 - lowest priority level, nice-to have things that require future discussion and design
            • Blocked

            Tech Debt - UIREQ-344 Deleting already-deleted request causes ungraceful error

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            New Feature - New feature requests UXPROD-2796 Prevent update conflicts when doing manual edits (User A and User B)

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            New Feature - New feature requests UXPROD-2797 Prevent update conflicts (1 user and system trying to act on the same record)

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Closed

            Bug - A problem which impairs or prevents the functions of the product. FOLIO-2027 Data Problems from Front-End Record Caching

            • P3 - low priority level, item will be considered for inclusion in the next dev cycle
            • Open

            Bug - A problem which impairs or prevents the functions of the product. MODINVSTOR-516 Cannot safely update holdings and items concurrently for any given instance

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            New Feature - New feature requests UXPROD-3089 Inventory. Implementing Optimistic Locking

            • P2 - normal priority level, must be included in the current development cycle
            • Closed

            Activity

              People

                jakub Jakub Skoczen
                charlotte Charlotte Whitt
                Votes:
                0 Vote for this issue
                Watchers:
                22 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved:

                  TestRail: Runs

                    TestRail: Cases