The Serialization Anomaly in Practice

Simulate real-world scenarios where concurrent transactions lead to invalid total states.

In this lesson, you will learn how to identify when concurrent transactions technically succeed but produce an invalid result that violates business rules.

A Serialization Anomaly occurs when the outcome of running transactions concurrently is impossible to achieve if the transactions were run one after another (serially). Even if your database uses locks or versioning to prevent basic data corruption, it might still allow "logical" corruption if you aren't using a strict Serialized isolation level.

The "Bank Transfer" Conflict

Imagine a bank system where the business rule states: "The sum of all balances in the system must never drop below zero."

Suppose we have two accounts, A and B, each with $100. The system total is$ 200. Now, two users attempt to withdraw $150 simultaneously.

The Timeline:

Transaction 1 checks SELECT SUM(balance) FROM accounts. It sees $200. It concludes, "I have enough funds," and prepares to subtract$ 150 from Account A.
Transaction 2 checks SELECT SUM(balance) FROM accounts. It also sees $200. It concludes, "I have enough funds," and prepares to subtract$ 150 from Account B.
Both transactions commit.

Individually, both transactions saw a valid state. However, the final state of the database is -$100. If these had run serially, the second transaction would have seen the impact of the first and been rejected.

The Practical Risk

In real-world applications, this often happens when your application logic makes a decision based on a read, then performs an update, without holding a lock that prevents other transactions from changing the "worldview" your decision was based on.

-- Transaction 1:
BEGIN;
SELECT SUM(balance) FROM accounts; -- Reads $200
-- Application logic: "200 - 150 > 0, so proceed"
UPDATE accounts SET balance = balance - 150 WHERE id = 'A';
COMMIT;

If you run this concurrently with an identical transaction, both processes confirm the balance is sufficient before either finishes the subtraction. The database sees no "conflict" because they are updating different rows, but the aggregate constraint is violated.

Key Takeaway: A serialization anomaly happens when concurrent transactions each perform valid individual actions that result in a collective state that could never exist in a serial, one-after-another execution.