[UXPROD-2994] Optimistic Locking: coordinate rollout of "failOnConflict" to selected modules and APIs Created: 15/Mar/21  Updated: 29/Jun/22

Status: Open
Project: UX Product
Components: None
Affects versions: None
Fix versions: TBD

Type: New Feature Priority: P2
Reporter: Jakub Skoczen Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: R2, cornell-priority, platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Defines
defines UXPROD-3058 Optimistic Locking In Progress
is defined by MODORDSTOR-225 Optimistic locking for pieces/po_line... Open
is defined by MODORGSTOR-106 Optimistic locking for organizations/... Open
is defined by MODINVSTOR-708 enable 'failOnConflict' for instances... Closed
is defined by MODINVSTOR-713 Enable support for optimistic locking... Closed
is defined by UXPROD-3089 Inventory. Implementing Optimistic Lo... Closed
is defined by MODNOTES-175 Optimistic locking for note_data Closed
Relates
relates to UXPROD-3048 Check that generated sequences cannot... Open
relates to UXPROD-1752 Prevent update conflicts (via optimis... Closed
relates to UXPROD-3089 Inventory. Implementing Optimistic Lo... Closed
Development Team: Core: Platform
PO Rank: 0
Rank: Chalmers (Impl Aut 2019): R4
Rank: Cornell (Full Sum 2021): R1
Rank: Duke (Full Sum 2021): R1
Rank: 5Colleges (Full Jul 2021): R1
Rank: U of AL (MVP Oct 2020): R1

 Description   

How

Optimistic Locking functionality in an RMB module is enabled for selected tables by changing configuration in the schema.json file. See https://github.com/folio-org/raml-module-builder#optimistic-locking. OL changes the behavior of the API and hence requires a major interface change.

Where

It has been discussed that OL 'failOnConflict' should be enabled for interfaces where there is a risk of concurrent access (and collisions). In mod-inventory storage this is done for instances/holdings/items.

What

POs: indicate interfaces where OL should be enabled by creating a specific backend issue and linking to this feature.



 Comments   
Comment by Tom Wilson [ 24/Mar/21 ]

All "interfaces" in which there could be conflict should have OL implemented. Any of the areas that have large data stores, e.g., users, inventory, srs, etc., would likely have conflicts between individual users and/or a user and an import process. 

Comment by Jakub Skoczen [ 12/Apr/21 ]

Tom Wilson Agree. I have created MODINVSTOR-708 Closed so far and it is scheduled for R2. Additional tickets in other modules must be created.

Comment by Kelly Drake [ 12/Apr/21 ]

Jakub Skoczen - will you be reaching out to the dev teams, or should I bring this to the POs?

Comment by Jakub Skoczen [ 20/Apr/21 ]

Kelly Drake What do you think is the best way forward?. So far I have created the rollout ticket for mod-inventory-storage ( MODINVSTOR-713 Closed ) and we will need similar tickets for other modules/APIs. Should I post a message to the PO channel and ask other POs to create these tickets for modules they are responsible for?

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

Hi Kelly Drake and Jakub Skoczen If this work is just about to land on several dev teams, we need to be clear about when this work needs to be delivered. My feeling is that we're too late for Juniper. If it needs to be part of Iris, then we need to understand the size of the work and have stories for every team/app where it's relevant. Thank you!

Comment by Jakub Skoczen [ 21/Apr/21 ]

Ann-Marie Breaux Kelly Drake I agree. I think Juniper is too short and too packed to fit this in. And this is a fairly disruptive change. How about we work with the POs to have the stories defined in Juniper but have the dev work happen in Kiwi?

Comment by Kelly Drake [ 21/Apr/21 ]

Jakub Skoczen and Ann-Marie Breaux  I've added this to the next PO meeting agenda.  This suggested timeline may not work for all teams but it's worth a shot.  Do you think we should use that meeting to get the POs starting in the process of defining the necessary stories, or should that work be done individually?

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

Jakub Skoczen and Kelly Drake I agree that Juniper is too short. I'm totally fine with Kiwi so long as the POs understand what needs to be done (hopefully some sort of model story or stories that we can copy) and that the SMEs understand this will take some of the Kiwi dev capacity for a number of dev teams.

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