Subversion Repositories SmartDukaan

Last modification

• Rev 37706 2026-09-18 04:20:00
• Author: amit

• Log message:

  cart: take the cart row before any line, to break a lock-ordering deadlock
  
  InnoDB was rolling back cart edits with "Deadlock found when trying to get lock"
  (GlitchTip #53, 27 deadlocks) and losing others to OptimisticLockException
  "actual row count: 0; expected: 1" (11 issues, 42 events). Both are the same cause.
  
  Two request paths took the same two rows in OPPOSITE orders. Adding a line INSERTs
  into user.line, and line_cart_id_fk shared-locks the parent cart FIRST, line second.
  Validation/hydration mutated the line rows FIRST and wrote cart.total_price second.
  Run those concurrently on one cart and it is a cycle. Caught in the act on prod:
  
  T1: INSERT user.line (cart_id=175180781) -> holds S on cart, waits S on line
  T2: UPDATE user.cart SET total_price=269340.0, version=175 WHERE version=174
  -> holds X on line, waits X on cart
  *** WE ROLL BACK TRANSACTION (1)
  
  Fix is to give every mutating path one order: cart, then lines. CartRepository gains
  selectByIdForUpdate, and it is called as the first statement of each path that writes
  a cart line. Re-taking it inside one request is a no-op.
  
  A lock-ordering fix is all-or-nothing -- one path in the wrong order is enough to
  re-form the cycle -- so this covers ALL TEN cart-line writers, not just the two that
  happened to show up in the stack traces: createCartItem, clearCart, getCartValidation,
  addItemsToCart (x2), addShoppingBag, validateForOpen (x2) and V2BillingController's
  bind/unbindInsurance. The audit is worth re-running before adding another writer.
  
  Note validateForOpen and getCartValidation WRITE despite their names (they correct
  cart_line quantity/price and roll up cart.total_price), which is why a "validate" call
  was ever holding write locks. The lock is placed accordingly; making those genuinely
  read-only is a separate, larger change.
  
  This also serialises concurrent edits to the SAME cart, which is what the @Version
  column on Cart was already trying and failing to express. Different carts are
  different rows, so there is no cost across partners.