Subversion Repositories SmartDukaan

Rev

Show changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
37706 19 d 4 h amit /trunk/ 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.
 
36376 165 d 15 h aman /trunk/ Feat:Cart Api Implementation  
35947 214 d 19 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ Revert r35945: undo cart pessimistic locking (will re-apply after testing)  
35945 214 d 20 h amit /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ Add pessimistic locking to cart operations to prevent deadlocks; add updateCartItem, removeCartItem, getCartItems methods  
22352 3323 d 19 h ashik.ali /trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/