Tag: Concurrency
All the articles with the tag "Concurrency".
-
Why You Cannot Simply Add a Second Instance to an In-Memory Pool
A second reputation-pool-cloud instance can grant the same resource twice, issue colliding JVM-local fencing tokens, and overwrite another instance's whole-snapshot checkpoint. This is a deterministic counterexample derived from the current code, not an observed production incident. The article traces the scope of leases, snapshots, memory budgets, and rate limits, then compares tenant sharding, externalized state, and a single writer.
-
Our 32-Thread Stress Test Passed. The Concurrency Specification Was Still Wrong.
A real account of adding Lincheck to reputation-pool. The checker did not merely find implementation bugs: it rejected three specifications that were stronger than the observable contract. This article follows the traces that separated per-resource fencing, schedule-dependent selection, and conservative acquisition failure.
-
JPA Optimistic Lock and the Retry Stampede Trap — 6 Scenarios @Version Cannot Cover Alone
100 workers each increment the same rule's priority by +1. Without @Version, the final priority < 100 (Lost Update). With @Version, you only get OptimisticLockException — handling is the caller's responsibility, so only some succeed. @Retryable(3) with backoff=0 produces **retry stampede** — retries pile up at the same instant, colliding again. Exponential backoff with full jitter spreads retries out and reaches priority=100. Plus the **self Lost Update** trap discovered along the way — same transaction, two SELECTs returning different objects (JDBC) vs the same instance (JPA first-level cache `==`). Different category from distributed Lost Update. The piece also covers @Transactional + @Retryable AOP ordering and the AWS Architecture Blog rationale for full jitter.
-
MySQL Credit Deduction — 4 Locks Compared, Pessimistic at 180ms / 100% accurate, plus the self-invocation trap I hit during measurement
An ordinary scenario — 100 workers concurrently subtracting 1 from an account with balance 100. Four lock strategies (optimistic / pessimistic / MySQL GET_LOCK / Redisson) all produce different results — pessimistic 180ms / 100% / balance 0, optimistic 549ms (retry storm under contention), GET_LOCK 5015ms (advisory lock cost), Redisson 53/100 (single-instance limitation). And during measurement I hit the self-invocation trap — successes=100 but the balance never moved. The real Spring/JPA pitfall is not logic, it is AOP proxy bypass. A walkthrough including direct demos of the connection-bound GET_LOCK traps in 4 scenarios.