A store is serializable and not linearizable. Two transactions each read a shared risk counter and write it back. Give a concrete outcome allowed under serializability and forbidden under linearizability, and say which property a pre-trade risk limit check actually needs.

A store is serializable and not linearizable. Two transactions each read a shared risk counter and write it back. Give a concrete outcome allowed under serializability and forbidden under linearizability, and say which property a pre-trade risk limit check actually needs.

Approach: Separate the property about the order of whole transactions from the property about real time on a single object, then construct a history that one permits and the other rejects.

A serializable store may run A, acknowledge it, then run B and place B before A in the equivalent serial order, so B reads a counter state from before A even though A completed first in real time; linearizability forbids that because it requires the order to respect real time on the object. Concretely, the counter starts at 0, A adds 100 and commits at 10:00:00.000, and B reads at 10:00:00.100, sees 0, and adds 100. Serializability only requires the result to match some serial order, and B then A is such an order producing a final value of 100, so 100 units of exposure disappear and the history is still legal. Linearizability requires any operation beginning after A completed to observe A, so B must read 100 and the counter ends at 200. Serializability is a property of multi object transactions and linearizability is a property of a single object under real time ordering, and neither implies the other. A pre-trade limit check needs strict serializability, which is both, because it spans several rows and must never read a state older than a trade already acknowledged.

Follow-up: Which anomaly does snapshot isolation permit that both of these forbid, and what does it do to a two leg hedge?

Key concepts: serializability, linearizability, real time ordering, strict serializability.