Questions: Serialization and Conflict Prevention Techniques

Question 1

A database guarantees SERIALIZABLE isolation. Which statement correctly describes what this means?

• A. All transactions must complete entirely before the next one is allowed to start
• B. Transactions may execute concurrently, but the results must be equivalent to some serial ordering of those transactions
• C. Transactions are sorted by start timestamp and executed in that order
• D. Only one transaction can hold a write lock at a time, serializing all writes

Answer: (B)

Serializability is about *outcomes*, not execution order. Transactions can overlap in time — reads and writes from different transactions can be interleaved — as long as the final database state is identical to what would result from running the transactions one after another in some order. This allows much more concurrency than literally serial execution while still guaranteeing correctness. Options A and C describe actual serial or timestamp-ordered execution; option D only serializes writes, not the full transaction.

Question 2

Two transactions T1 and T2 run concurrently at SERIALIZABLE isolation under MVCC. T1 reads account balances; T2 updates one. At commit time, the system detects a conflict and aborts T2. A developer says: 'MVCC is broken — we paid for SERIALIZABLE isolation but our transaction was aborted.' What is the correct response?

• A. The developer is correct; SERIALIZABLE isolation should prevent all transaction aborts
• B. The abort IS how MVCC enforces serializability — allowing T2 to commit would produce a non-serializable result, so the system aborts and retries rather than committing invalid data
• C. MVCC cannot provide SERIALIZABLE isolation; the developer should switch to 2PL to avoid aborts
• D. T2 should have been allowed to commit because it only wrote data, not read the conflicting rows

Answer: (B)

MVCC achieves serializability optimistically: it lets transactions proceed without blocking and checks for conflicts at commit time. An abort means the system found that committing T2 would produce a result inconsistent with any serial order — so it aborts and retries rather than corrupt the database. This is correct behavior, not a bug. Under 2PL, T2 would have *waited* (blocked) for T1's lock instead of aborting — different mechanism, same correctness guarantee. An abort is MVCC's version of a lock wait.

Question 3

Two read-only transactions can always execute in parallel without violating SERIALIZABLE isolation, regardless of the isolation mechanism.

• T. True
• F. False

Answer: True

Read-only transactions never write, so they cannot create write-write or write-read conflicts with each other. Any interleaving of two read-only transactions produces a result equivalent to running them serially in either order (since neither modifies anything). This is one practical advantage of MVCC: read-only transactions can proceed entirely without locks or version checks against each other, enabling high read concurrency even at SERIALIZABLE isolation.

Question 4

Two-phase locking (2PL) prevents conflicts by requiring transactions to release their existing locks before acquiring new ones.

• T. True
• F. False

Answer: False

This is exactly backwards. Two-phase locking requires the opposite: during the 'growing phase,' a transaction acquires locks and may not release any. Only after entering the 'shrinking phase' does it start releasing locks — and then it may not acquire new ones. The rule is: once you start releasing, you stop acquiring. This growing-then-shrinking pattern is what guarantees conflict serializability. If transactions could release and re-acquire freely, a non-serializable interleaving would become possible.

Question 5

What is the fundamental difference in how 2PL and MVCC achieve serializability, and what does this mean for concurrent read-only transactions?

Model answer: 2PL achieves serializability by blocking: transactions acquire locks before accessing data and hold them until commit, so conflicting operations from other transactions must wait. MVCC achieves serializability by versioning: readers see a consistent snapshot from their transaction's start time and never block writers, and the system checks for conflicts only at commit time, aborting if necessary. For read-only transactions, this distinction is critical: under MVCC, read-only transactions require no locks and never block or get blocked, enabling full read parallelism. Under 2PL, even read-only transactions must acquire shared locks, which can delay writers and create contention.

The design philosophy differs: 2PL is pessimistic (assume conflicts will happen, so prevent them upfront with locks) while MVCC is optimistic (assume conflicts are rare, so proceed without blocking and only check at commit). Both guarantee serializability; the tradeoff is throughput vs. abort rate under different workload patterns.