Conflict Serializability in DBMS
Last Updated :
16 Jun, 2025
A schedule is a sequence in which operations (read, write, commit, abort) from multiple transactions are executed in a database. Serial or one by one execution of schedules has less resource utilization and low throughput. To improve it, two or more transactions are run concurrently.
- Conflict Serializability guarantees that even though transactions run concurrently, their outcome will be identical to the result achieved if the transactions were executed one by one in a specific order.
- It is a concept in concurrency control that determines whether a non-serial schedule can be rearranged to act like a serial schedule without conflicts.
- It ensures data consistency when multiple transactions are executed at the same time.
- There is another type of serializability called view serializability, which is less restrictive than conflict serializability.
Non-conflicting operations: Two operations are considered non-conflicting if they operate on separate data items, or if they involve the same data item but both are read operations.
Conflicting Operations
Two operations are said to be conflicting if all conditions are satisfied:
- They belong to different transactions
- They operate on the same data item
- Atleast one of them is a write operation
Conflicting OperationsConsider the following schedule:
S1: R1(A), W1(A), R2(A), W2(A), R1(B), W1(B), R2(B), W2(B)
If Oi and Oj are two operations in a transaction and Oi< Oj (Oi is executed before Oj), same order will follow in the schedule as well. Using this property, we can get two transactions of schedule S1:
T1: R1(A), W1(A), R1(B), W1(B)
T2: R2(A), W2(A), R2(B), W2(B)
Possible Serial Schedules are: T1->T2 or T2->T1
-> Swapping non-conflicting operations R2(A) and R1(B) in S1, the schedule becomes,
S11: R1(A), W1(A), R1(B), W2(A), R2(A), W1(B), R2(B), W2(B)
-> Similarly, swapping non-conflicting operations W2(A) and W1(B) in S11, the schedule becomes,
S12: R1(A), W1(A), R1(B), W1(B), R2(A), W2(A), R2(B), W2(B)
S12 is a serial schedule in which all operations of T1 are performed before starting any operation of T2. Since S has been transformed into a serial schedule S12 by swapping non-conflicting operations of S1, S1 is conflict serializable.
Let us take another Schedule:
S2: R2(A), W2(A), R1(A), W1(A), R1(B), W1(B), R2(B), W2(B)
Two transactions will be:
T1: R1(A), W1(A), R1(B), W1(B)
T2: R2(A), W2(A), R2(B), W2(B)
Possible Serial Schedules are: T1->T2 or T2->T1
Original Schedule is as:
S2: R2(A), W2(A), R1(A), W1(A), R1(B), W1(B), R2(B), W2(B)
Swapping non-conflicting operations R1(A) and R2(B) in S2, the schedule becomes,
S21: R2(A), W2(A), R2(B), W1(A), R1(B), W1(B), R1(A), W2(B)
Similarly, swapping non-conflicting operations W1(A) and W2(B) in S21, the schedule becomes,
S22: R2(A), W2(A), R2(B), W2(B), R1(B), W1(B), R1(A), W1(A)
In schedule S22, all operations of T2 are performed first, but operations of T1 are not in order (order should be R1(A), W1(A), R1(B), W1(B)). So S2 is not conflict serializable.
Conflict Equivalent
If a schedule S can be transformed into a schedule S´ by a series of swaps of non-conflicting instructions, we say that S and S´ are conflict equivalent. We say that a schedule S is conflict serializable if it is conflict equivalent to a serial schedule.
Note 1: In the above example, Although S2 is not conflict serializable, still it is conflict equivalent to S21 and S22 because S2 can be converted to S21 and S22 by swapping non-conflicting operations.
Note 2: The schedule which is conflict serializable is always conflict equivalent to one of the serial schedule. S1 schedule discussed above (which is conflict serializable) is equivalent to the serial schedule (T1->T2).
Read more about Equivalent Serial Schedule of Conflict Serializable Schedule in DBMS.
Gate Question-2007
Testing Conflict Serializability
To test whether a schedule is conflict-serializable, you can use the precedence graph (or conflict graph). The process involves the following steps:
- Identify Conflicting Operations: Conflicts occur when two transactions access the same data item, and at least one of them is a write operation. Common conflicts are:
- Write-Read (WR): A transaction writes a data item, and another transaction reads it.
- Read-Write (RW): A transaction reads a data item, and another transaction writes to it.
- Write-Write (WW): Two transactions write to the same data item.
- Construct the Precedence Graph:
- Create a node for each transaction in the schedule.
- Draw a directed edge from transaction Ti to transaction Tj if Ti performs a conflicting operation before Tj.
- Check for Cycles:
- If the precedence graph has no cycles, the schedule is conflict-serializable.
- If there are cycles, the schedule is not conflict-serializable.
Read more about Precedence Graph for Testing Conflict Serializability in DBMS here.
Advantages of Conflict Serializability
- Consistency: Conflict serializability guarantees that the transactions' outcomes correspond to the sequence in which they were carried out.
- Correctness: Regardless of the order in which transactions were submitted, conflict serializability guarantees that transactions are executed correctly.
- Decreased Overhead: By doing away with pointless locking and other conflict resolution techniques, conflict serializability lowers overhead.
- Enhanced Concurrency: By enabling concurrent execution of operations without causing conflicts, conflict serializability enhances concurrency.
Disadvantages of Conflict Serializability
- Complexity: Conflict serializability can be complex to implement, especially in large and complex databases.
- Reduced Performance: Conflict serializability can reduce performance by introducing delays and overhead due to locking and other conflict resolution mechanisms.
- Limited Concurrency: Conflict serializability can limit the degree of concurrency in the system because it may delay some transactions to avoid conflicts.
- Increased Overhead: Conflict serializability requires additional overhead to maintain the order of the transactions and ensure that they do not conflict with each other.
Similar Reads
Dependency Preserving Decomposition - DBMS In a Database Management System (DBMS), dependency-preserving decomposition refers to the process of breaking down a complex database schema into simpler, smaller tables, such that all the functional dependencies of the original schema are still enforceable without needing to perform additional join
7 min read
Lossless Join and Dependency Preserving Decomposition Decomposition of a relation is done when a relation in a relational model is not in appropriate normal form. Relation R is decomposed into two or more relations if decomposition is lossless join as well as dependency preserving. Lossless Join DecompositionIf we decompose a relation R into relations
4 min read
How to find the highest normal form of a relation Normalization is the process of structuring data in a database by creating tables and defining relationships between them. This ensures data consistency, protection, and improves the database's efficiency and flexibility. Typically, every table in a relational database is assumed to be in the first
5 min read
Equivalence of Functional Dependencies Equivalence of functional dependencies means two sets of functional dependencies (FDs) are considered equivalent if they enforce the same constraints on a relation. This happens when every FD in one set can be derived from the other set and vice versa using inference rules like Armstrong's axioms.Eq
5 min read
Canonical Cover of Functional Dependencies in DBMS Managing a large set of functional dependencies can result in unnecessary computational overhead. This is where the canonical cover becomes useful. The canonical cover of a set of functional dependencies F is a simplified version of F that retains the same closure as the original set, ensuring no re
7 min read
Structured Query Language (SQL) Structured Query Language is a standard Database language that is used to create, maintain, and retrieve the relational database. In this article, we will discuss this in detail about SQL. Following are some interesting facts about SQL. Let's focus on that. SQL is case insensitive. But it is a recom
6 min read
Inner Join vs Outer Join Inner Join and Outer Join are the types of join. The inner join has the work to return the common rows between the two tables, whereas the Outer Join has the work of returning the work of the inner join in addition to the rows that are not matched. Let's discuss both of them in detail in this articl
9 min read
Having vs Where Clause in SQL In SQL, filtering data is important for extracting meaningful insights from large datasets. While both the WHERE and HAVING clauses allow us to filter data, they serve distinct purposes and operate at different stages of the query execution process. Understanding the difference between these clauses
4 min read
Concurrency Control in DBMS In a database management system (DBMS), allowing transactions to run concurrently has significant advantages, such as better system resource utilization and higher throughput. However, it is crucial that these transactions do not conflict with each other. The ultimate goal is to ensure that the data
7 min read
Database Recovery Techniques in DBMS Database Systems like any other computer system, are subject to failures but the data stored in them must be available as and when required. When a database fails it must possess the facilities for fast recovery. It must also have atomicity i.e. either transactions are completed successfully and com
11 min read