Loading...
Loading...
Browse 4 real-world technical and behavioral interview questions about Locking. Review scenarios, edge cases, and architectural best practices.
This is write skew: two transactions read the same set, each writes a different row, and the pair commits a state neither would have produced alone. No row-level constraint can catch it because the invariant is a property of the set, so the fix is either serializable isolation, a lock on something both transactions must touch, or remodelling the invariant onto a single row.
A deadlock is a cycle in the wait-for graph, so read the engine's own report to get both statements and the locks each held. Nearly all of them come from two code paths taking the same rows in different orders; impose one order, shorten transactions, and retry, because a deadlock is always safe to retry.
Thread-safe component design starts by assigning every field a policy: confined, immutable or guarded by a named lock. Method-level synchronization is not enough because atomic methods do not compose into atomic workflows.
Thread safety composes per operation, not across operations. A get followed by a put is two atomic steps with a legal interleaving between them. You close the window by making the whole compound action one operation, such as compute or merge, or by holding a single lock across both steps.