Subversion Repositories SmartDukaan

Last modification

• Rev 36372 2026-04-24 12:46:08
• Author: amit

• Log message:

  Wallet: SELECT FOR UPDATE on user_wallet mutations to close lost-update hole
  
  addAmountToWallet/consumeAmountFromWallet(x2)/rollbackAmountFromWallet all
  follow a read-modify-write pattern on user_wallet with no pessimistic lock
  and no @Version, so two concurrent tx for the same partner both read the
  same pre-snapshot amount, compute their own deltas, and commit - the second
  UPDATE silently overwrites the first's credit/debit. user_wallet_history
  still gets both rows, so balance drifts vs sum(history) with no exception.
  
  Replaces the misnamed (and body-broken) selectByIdForUpdate - whose
  implementation was a plain selectById, not a lock - with a new
  selectByRetailerIdForUpdate that issues SELECT ... FOR UPDATE via
  LockModeType.PESSIMISTIC_WRITE, mirroring the idiom already used in
  GenericRepositoryImpl.selectByIdForUpdate and OrderRepositoryImpl.
  Preserves the create-on-missing behavior of selectByRetailerId so
  first-time partners keep working.
  
  Switches the four read-modify-write call sites in WalletServiceImpl from
  selectByRetailerId to the new locking variant. Read-only callers
  (getUserWalletByUserId, getUserWalletHistoryByUserId, etc.) keep using
  the non-locking selectByRetailerId - MVCC snapshot reads stay non-blocking
  for display/statement endpoints.
  
  Also drops the stale commented-out selectByIdForUpdate line in
  rollbackAmountFromWallet and removes the broken method from the
  UserWalletRepository interface / impl - it had zero live callers.
  
  Blast radius: every write call to these three wallet methods now holds
  an X-lock on the target user_wallet row for the rest of the outer tx.
  Concurrent write tx for the same partner will briefly serialize at the
  SELECT FOR UPDATE - correct serialization instead of silent drift.
  Read-only traffic is unaffected (MVCC).