Spike: Optimistic Locking for Acquisition

Overview

Optimistic Locking is a technical solution provided by RMB and other frameworks to resolve update conflicts. See UXPROD-3058 for background information.

All acquisition apps are currently vulnerable to update conflicts. What this means in practice is that if 2 users are updating the same record at the same time, one of them might lose its modifications and will receive no warning. Additionally, all derived modifications are vulnerable too: if an edit triggers another edit in another module, these modifications can be lost too without a warning.

Modules using other modules that have optimistic locking enabled need to check for the 409 status code, and react appropriately, for instance by minimizing risks of update conflicts, or trying the update sequence again, or report an explicit error to the user (or all 3). This means all layers require modifications.

Spike Objectives

• Discuss optimistic locking in a team meeting.
• Evaluate the effort required.
• Create a wiki page with a few background links, and a table with all modules and the status of optimistic locking implementation for each: storage layer, business layer, and UI, and all the related tickets.

Spike Decisions

• Decide on which modules and tables to start optimistic locking with.
• Decide on a timeline. Which release will have complete optimistic locking for acquisition apps ?