When can sticky locks cause a problem in a distributed Mnesia cluster?

A sticky lock optimizes for the common case where the same node keeps writing to a table, but it means lock "ownership" has to be reclaimed if a different node suddenly needs to write — and if the node currently holding the sticky lock has become unreachable (crashed, network partition), reclaiming that lock can take noticeably longer than an ordinary non-sticky lock request would.

flowchart TD
    A[NodeB wants to write, lock is sticky to NodeA] --> B{Is NodeA reachable?}
    B -->|Yes| C[Lock ownership transferred to NodeB, then proceeds]
    B -->|No, NodeA down/partitioned| D[Extra delay reclaiming lock ownership before NodeB can proceed]

This is why sticky locks are a good fit for workloads with a genuinely stable, dominant writer per table, but a poor fit for workloads where write ownership legitimately shifts between nodes frequently — in that case, the overhead of repeatedly reclaiming sticky ownership can end up costing more than the round-trips it was meant to save.