Serial vs Serializable - Transactions and Schedules

Serial versus serializable

A serial trace runs one transaction after another. An interleaved trace can still be conflict-serializable when its graph is acyclic. Note: the contrast is decided by graph structure, not by visual interleaving alone.

\text{serializable contrast}

Cyclic side

The cyclic side has recomputed cycle length 2. Note: the highlighted cycle is the reason the rendered verdict changes.

\text{cycle length}=2

conflict-serializability is an exact SUFFICIENT criterion; a cyclic precedence graph is provably not conflict-serializable; view-serializability, lock scheduling, and recovery are beyond these tiny traces - no product claims.

Acyclic side

The acyclic side has cycle length 0 and topo length 2. Note: the topo order appears in the render.

\text{cycle length}=0,\quad \text{topo length}=2

conflict-serializability is an exact SUFFICIENT criterion; a cyclic precedence graph is provably not conflict-serializable; view-serializability, lock scheduling, and recovery are beyond these tiny traces - no product claims.

Side by side

Both schedules are compiled independently, and each verdict is rendered from its own graph. Note: the same exact rule handles both traces.

\text{same rule}

conflict-serializability is an exact SUFFICIENT criterion; a cyclic precedence graph is provably not conflict-serializable; view-serializability, lock scheduling, and recovery are beyond these tiny traces - no product claims.

Summary

Serializable is a graph property here: acyclic schedules have a serial order, cyclic schedules do not. Note: conflict-serializability is exact here; view-serializability, locks, and recovery are deferred.

\text{contrast summary}