Serializability

Operations Conflict

Conflicts come from same-item operations across transactions when a write is involved.

highlighted = computed this step

Conflicts create ordering pressure

Two operations conflict only when they touch the same item, belong to different transactions, and at least one writes. Read with read does not conflict. Note: commit and abort do not create conflict edges.

conflict rule\text{conflict rule}

Read write conflict

The first example recomputes 1 precedence edge. Note: the edge appears because a write is involved.

edges=1\text{edges}=1

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.

Conflicting operationsstepT1T20R(A)1W(A) conflict-serializable: yes; topo: T1,T2T1T2

Read read contrast

The read-read example recomputes 0 precedence edges. Note: shared reads do not force an order.

edges=0\text{edges}=0

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.

Read read contraststepT1T20R(A)1R(A) conflict-serializable: yes; topo: T1,T2T1T2

Summary

The conflict rule is local, but its edges become a global graph. Note: conflict-serializability is exact here; view-serializability, locks, and recovery are deferred.

conflicts to graph\text{conflicts to graph}