A banking application runs two concurrent transactions: T1 sums the balances of all accounts, and T2 deposits money into one account. Under SERIALIZABLE isolation, which outcome is possible?
AT1 reads the same account's balance both before and after T2's deposit within a single scan
BT2's deposit appears in some but not all of T1's reads of that account
CThe result is identical to T1 completing entirely before T2, or T2 completing entirely before T1
DT1 and T2 freely interleave since SERIALIZABLE only prevents dirty reads
SERIALIZABLE guarantees that the result of concurrent execution is indistinguishable from some serial execution. T1 will see either all of T2's changes or none — as if they ran one after the other. Options A and B describe phantoms and non-repeatable reads that SERIALIZABLE specifically prevents. Option D confuses SERIALIZABLE with READ COMMITTED, the weakest level that prevents only dirty reads.
Question 2 Multiple Choice
PostgreSQL implements SERIALIZABLE using Serializable Snapshot Isolation (SSI) rather than strict two-phase locking (2PL). What is the key operational difference?
ASSI prevents more anomalies than strict 2PL, including dirty writes that 2PL cannot prevent
BSSI lets transactions work concurrently on snapshots and aborts conflicting transactions at commit time rather than blocking them with locks
CSSI only applies to read-only transactions; 2PL handles transactions that write
DSSI requires explicit LOCK TABLE statements in application code, while 2PL acquires locks automatically
The core difference is blocking vs. abort-and-retry. Strict 2PL blocks one transaction while another holds a conflicting lock, reducing parallelism. SSI lets all transactions run on consistent snapshots, tracks dependency patterns between them, and aborts any transaction whose execution pattern creates a cycle that would make the result non-serializable. Applications must include retry logic for aborted transactions. Both approaches achieve the same correctness guarantee but with different performance characteristics.
Question 3 True / False
Under SERIALIZABLE isolation, some transactions may be aborted mid-execution and require application-level retry logic to handle.
TTrue
FFalse
Answer: True
This is the practical cost of SERIALIZABLE. SSI-based implementations (like PostgreSQL) abort transactions when they detect a 'dangerous structure' — a dependency cycle indicating non-serializability. The aborted transaction must be retried. Strict 2PL avoids aborts (using blocking instead) but can deadlock, which also requires retry. Applications targeting SERIALIZABLE must be designed to retry on serialization failures.
Question 4 True / False
SERIALIZABLE isolation guarantees that concurrent transactions execute in the exact chronological order they were submitted to the database.
TTrue
FFalse
Answer: False
SERIALIZABLE guarantees equivalence to *some* serial order — not necessarily the order of submission. The database chooses (or discovers) a valid serial ordering that matches what actually happened. In SSI, concurrent transactions may partially overlap in time; the guarantee is that the resulting data state looks as though they ran one at a time in some order. The actual submission order is irrelevant to serializability.
Question 5 Short Answer
Explain why 'equivalent to a serial execution' is different from 'executed serially,' and why this distinction matters for a high-throughput database.
Think about your answer, then reveal below.
Model answer: Executing transactions serially — one at a time with no overlap — would eliminate all concurrency anomalies but also eliminate concurrency itself, giving the throughput of a single-threaded system. 'Equivalent to a serial execution' means the database can still run transactions concurrently (lapping each other in time), as long as the final committed state is identical to what some serial order would produce. This preserves correctness while allowing the parallelism needed for performance. SSI achieves this by detecting dangerous interleavings and aborting them rather than preventing all overlap.
The distinction is between the *outcome* of execution (which must look serial) and the *process* of execution (which can be concurrent). High-throughput databases like PostgreSQL serve thousands of transactions per second — true serial execution would create a bottleneck. SERIALIZABLE at the outcome level preserves correctness guarantees that applications depend on (no phantom reads, no write skew) while still allowing the database engine to schedule transactions with substantial overlap.