Details
-
Task
-
Status: Closed (View Workflow)
-
TBD
-
Resolution: Won't Do
-
None
-
None
-
None
-
5
-
Thunderjet
-
Nolana (R3 2022)
-
TBD
Description
Purpose/Overview:
Create a POC implementation in separate branches to demonstrate a solution taking into account the cases and issues we collected in MODFISTO-292.
In particular, we are looking for a solution that supports not just parallel sets of transactions in mod-finance-storage, but also larger operations where mod-orders and mod-invoice get some data, modify it, and send requests to update the records.
Using locks to delay operations until resources are available, and returning errors to users to suggest trying operations later are both acceptable solutions, as long as parallel requests do not result in an inconsistent state.
TestRail: Results
Attachments
Issue Links
- blocks
-
MODFISTO-259 Releasing 2 transactions at the same time can fail to update budgets
-
- Blocked
-
-
MODINVOICE-307 Update transaction summary API calls
-
- Closed
-
- defines
-
UXPROD-3636 Define new transaction model to protect against parallel processing
-
- Closed
-
- relates to
-
MODORDERS-681 Errors when creating pieces in quick succession
-
- Closed
-
-
MODFISTO-303 Enable optimistic locking
-
- Closed
-
-
MODFISTO-304 Lock budgets to update totals
-
- Closed
-