When multiple transactions run concurrently, the DBMS interleaves their operations into a schedule. Not all interleaved schedules are safe. Conflict serializability is a key idea that tells us whether a non‑serial schedule is “good enough” to be allowed without breaking consistency.

In simple terms, a conflict serializable schedule is a non‑serial schedule that behaves exactly like some serial schedule, as long as we only care about conflicts between operations.

What Is a Conflict?

Two operations from different transactions are said to conflict if they:

1. Access the same data item (for example, the same attribute or tuple).

2. At least one of them is a write operation.

For example:

• $T_1$.write(A) and $T_2$.read(A) → conflict

• $T_1$.read(A) and $T_2$.write(A) → conflict

• $T_1$.write(A) and $T_2$.write(A) → conflict

• $T_1$.read(A) and $T_2$.read(A) → no conflict (only reads)

The intuition is that a write changes the value, so it must not be “mixed in” with another transaction’s operations in a harmful way.

What Is Conflict Serializability?

A schedule is conflict serializable if it can be transformed into a serial schedule by swapping only non‑conflicting operations.

In other words:

“If I can reorder some operations that do not conflict, and the final result becomes the same as some serial schedule, then the original schedule is conflict serializable.”

Such a schedule is considered correct for concurrency control because its effect is equivalent to running transactions one after another.

Example Sketch

Suppose two transactions:

• $T_1$: read(A), write(A)

• $T_2$: read(A), write(A)

A non‑serial but conflict serializable schedule might be:

1. $T_1$.read(A)

2. $T_2$.read(A)

3. $T_2$.write(A)

4. $T_1$.write(A)

Even though the operations are interleaved, the final value of A and the relative order of conflicting writes make its effect equivalent to one serial order (for example, $T_1$ first, then $T_2$, or vice versa after legal swaps).

Schedules that are not conflict serializable can cause lost updates, wrong results, or inconsistency.

How to Check Conflict Serializability (Concept)

In practice, DBMS designers use tools like the precedence graph to decide conflict serializability:

1. Create a graph where each node is a transaction.

2. Draw a directed edge from $T_i$ to $T_j$ if $T_i$ has a conflicting operation that comes before a conflicting operation of $T_j$ in the schedule.

3. If the graph has no cycles, the schedule is conflict serializable.

4. If the graph has a cycle, the schedule is not conflict serializable.

For beginners, the key idea is:

• Swaps that do not involve conflicts are allowed.

• If, after all such safe swaps, the schedule becomes serial, it is conflict serializable and safe.

Why Conflict Serializability Matters?

• It is the main criterion for deciding whether a concurrent schedule is acceptable.

• Most concurrency control protocols (locking, timestamping, etc.) aim to generate only conflict serializable schedules.

• It gives a simple, operational way to reason about correctness without simulating every possible interleaving.

Summary

Conflict serializability in DBMS is a property of a schedule that says its effect is equivalent to some serial schedule, if we only reorder non‑conflicting operations. A schedule is conflict serializable if it can be transformed into a serial schedule by swapping operations that do not access the same data item with at least one write. This concept is central to concurrency control because it identifies which interleaved schedules are safe to allow while still giving the benefits of parallel execution.