Budget management functionality that FOLIO needs to stay competitive (UXPROD-3442)

[UXPROD-3636] Define new transaction model to protect against parallel processing Created: 18/Apr/22  Updated: 30/May/23  Resolved: 30/May/23

Status: Closed
Project: UX Product
Components: None
Affects versions: None
Fix versions: None
Parent: Budget management functionality that FOLIO needs to stay competitive

Type: New Feature Priority: P3
Reporter: Dennis Bridges Assignee: Dennis Bridges
Resolution: Won't Do Votes: 0
Labels: acquisitions, tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Cloners
clones UXPROD-3434 Implement new finance transaction mod... Closed
Defines
is defined by MODFISTO-292 Spike : Collect possible cases with p... Closed
is defined by MODFISTO-297 Spike: Proof of concept to support pa... Closed
Release: Nolana (R3 2022)
Epic Link: Budget management functionality that FOLIO needs to stay competitive
Front End Estimate: Out of scope
Development Team: Thunderjet
PO Rank: 0
Rank: Cornell (Full Sum 2021): R2

 Description   

Split:

This was split from UXPROD-3434 Closed to allow the team time to define an approach and implement a POC. The actual solution will need to be implemented in a following release. The decision was motivated by the time constraints surrounding the MG release

 

Current situation or problem: When 2 users or separate mods run operations in parallel, they can send both summaries before sending the operations. mod-finance-storage is not saving previous summaries with the same id (which in practice is the order id for encumbrances), so one of the summaries sent will have no effect, resulting in an error for the second one:

"All expected transactions already processed"

In scope

Implement a POC: Redesign transaction summaries to allow parallel usage. Using unique ids (as opposed to for instance order ids)  could be part of the solution, but we don't want to accumulate too many records in the summary tables, so they would have to be deleted when no longer in use.

 When redesigning, care should be taken to avoid requiring a check for 404 errors, as was done in mod-orders' TransactionSummariesService.java for MODORDERS-545 Closed (normal operations should not report errors in the logs).

Out of scope

Actual implementation of the chosen approach in the Finance app

Use case(s)

Proposed solution/stories
Wiki : https://folio-org.atlassian.net/wiki/display/DD/Support+for+transaction+processing+by+two+or+more+users+in+parallel

Links to additional info

Questions



 Comments   
Comment by Dennis Bridges [ 11/May/22 ]

Moved to Nolana as this investigation could not be completed without more information. Developers recommended working on optimistic locking before parallel processing.

Comment by Dennis Bridges [ 04/Jul/22 ]

Not likely that Jet will have capacity to work on this during Nolana as we need to review what the most critical areas are for improving the stability of financial transaction management in FOLIO before we proceed with more updates.

Comment by Damien [ 30/May/23 ]

This is deprecated by UXPROD-4321 Open .

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