Details
-
Story
-
Status: Closed (View Workflow)
-
P3
-
Resolution: Done
-
None
-
None
-
ACQ Sprint 141
-
2
-
Thunderjet
-
Morning Glory (R2 2022)
-
TBD
Description
Purpose/Overview:
Currently budget updates can conflict when 2 transactions are applied in parallel for the same budget. We can prevent this issue by locking the budgets with Postgres when getting budgets/applying changes/updating them.
Requirements/Scope:
Use a Postgres lock in EncumbranceService$updateBudgetsTotals, PaymentCreditService$updateBudgetsTotals, and PendingPaymentService.
Approach:
- Use a Postgres transaction. There is already one created in AllOrNothingTransactionService, so we probably don't need to do anything.
- Use SELECT ... FOR UPDATE when getting the budgets to update (add getBudgetsForUpdate() to budgetService).
- Make sure the transaction is ended at the end, or rolled back if an error occurs (this is already done in AllOrNothingTransactionService).
- Use the parallel-update-order-lines-different-orders test from
MODFISTO-260.
Acceptance criteria:
- parallel-update-order-lines-different-orders never fails anymore.
- Unit tests and integration tests (finance, orders, invoices, cross-module) pass.
TestRail: Results
Attachments
Issue Links
- defines
-
UXPROD-3663 Part 1 - Finance - Implementing Optimistic Locking
-
- Closed
-
-
UXPROD-3666 Improve support for parallel processing
-
- In Refinement
-
- has to be done after
-
MODFISTO-303 Enable optimistic locking
-
- Closed
-
- has to be done before
-
MODFISTO-314 POC: fix the transaction API
-
- Closed
-
-
STSMACOM-668 ControlledVocab - optimistic locking
-
- Closed
-
-
UIF-379 Finance optimistic locking
-
- Closed
-
-
UISACQCOMP-104 Create common component OptimisticLockingBanner
-
- Closed
-
- relates to
-
MODFISTO-259 Releasing 2 transactions at the same time can fail to update budgets
-
- Blocked
-
-
MODFISTO-297 Spike: Proof of concept to support parallel requests
-
- Closed
-