| 35424 |
28 d 1 h |
amit |
/trunk/ |
Fix order billing vs cancellation race condition with pessimistic locking
Problem:
- Concurrent billing and cancellation of the same order caused data inconsistency
- Money was refunded to wallet while order was also getting billed
Solution:
- Added pessimistic locking (SELECT FOR UPDATE) to prevent concurrent modifications
- Added validation methods to check order state before billing/cancellation
- Optimized billing method to reduce lock duration with pre-fetching
Changes:
- OrderRepository: Added selectByIdForUpdate, selectByOrderIdsForUpdate,
selectByInvoiceNumbersForUpdate, selectAllByTransactionIdForUpdate,
validateOrdersForBilling, validateOrderForRefund methods
- OrderRepositoryImpl: Implemented locking methods with PESSIMISTIC_WRITE
- TransactionServiceImpl: Updated billing methods with locking, fail-fast
validation, pre-fetching to avoid N+1 queries
- ScheduledTasks: Updated removePartialBillingForTransaction with locking
- TransactionRelatedTasks: Updated reverseRTO with locking |
|