DBMS - Conflict Serializability

When we are working on database transactions, we often consider multiple transactions consecutively. When multiple transactions run simultaneously, there is a risk of conflicts that can lead to incorrect results. For that purpose, we need to serialize schedules. There are multiple types of serializability. Conflict serializability is one of them. It ensures transactions are processed correctly without causing inconsistencies. Read this chapter to learn the concept of conflict serializability in detail.

Schedules in DBMS

To understand the idea of conflict serializability, we must first understand what a schedule is. In DBMS, a schedule is a sequence of transaction operations (like reads or writes). These operations are arranged in a specific order. It is determines how transactions are executed. Specially when multiple transactions run concurrently.

Serial Schedule

When we are talking one schedules we must consider serial and non-serial schedules. A serial schedule processes transactions one after another without overlapping. For example: Transaction T1 runs entirely before Transaction T2 begins.

This kind of schedule is straightforward and always consistent because transactions are isolated from one another. But, it can be slow due to the lack of concurrency. Here is an example of a serial schedule −

In this example, T2 completes both its operations before T1 starts. Since transactions do not overlap, the schedule is guaranteed to be consistent.

Non-Serial Schedule

On the other hand, a non-serial schedule allows multiple transactions to overlap. This means some operations from different transactions may run simultaneously. This increases efficiency by reducing waiting time. It can lead to inconsistencies if not managed carefully. Here is an example of a non-serial schedule −

Here, transactions T1 and T2 run concurrently. While this improves performance. There is no immediate guarantee of consistency.

Importance of Conflict Serializability

While serial schedules are always consistent. But they are inefficient. Non-serial schedules, on the other hand, allow for better concurrency. But can cause issues if transactions interfere with one another.

The conflict serializability helps to determine if a non-serial schedule can be rearranged into a serial one by swapping non-conflicting instructions or not. If it can be transformed into a serial schedule then the system can guarantee consistency while allowing parallel execution.

Conflicting Instructions

To determine whether a non-serial schedule is conflict serializable, we need to identify when two instructions conflict.

What Makes Instructions Conflicting?

• They belong to different transactions.
• They operate on the same data item.
• At least one of them is a write operation.

If all three conditions are met, the instructions are said to be in conflict. So it means they cannot be swapped without changing the final result.

Examples of Conflicting and Non-Conflicting Instructions

Let us see some examples to understand this better −

Example 1: Non-Conflicting Instructions

Since these instructions operate on different data items (A and B), they are non-conflicting. We can swap them without changing the result.

• T1: Read(A)
• T2: Write(B)

Example 2: Conflicting Instructions

Here, both instructions work on the same data item A. One of them is a write operation. This makes them conflicting, this means they cannot be swapped.

• T1: Read(A)
• T2: Write(A)

Example 3: Write-Write Conflict

Even though both instructions are write operations, the final value of A depends on which operation happens last. This creates a conflict. So swapping them would change the outcome.

• T1: Write(A)
• T2: Write(A)

Real-Life Analogy for Conflicts

Imagine two chefs working in a kitchen −

• Chef 1 prepares a salad.
• Chef 2 bakes a cake.

Since they are working on different dishes, they can work simultaneously. But if both chefs try to use the oven at the same time, it will make a conflict because only one person can use the oven at once. Similarly, in DBMS, conflicts occur when transactions compete for the same data item.

Checking for Conflict Serializability

Let us take a closer look at how to check if a schedule is conflict serializable using a practical example.

Example Schedule

Step 1: Identify Transactions and Data Items

• T1 works on A.
• T2 works on B.

Since A and B are different data items, the instructions from T1 and T2 are non-conflicting.

Step 2: Attempt to Rearrange Instructions

We can rearrange the schedule as follows −

This order matches a serial schedule where T2 completes before T1 starts.

Since we could rearrange the original non-serial schedule into a serial schedule by swapping non-conflicting instructions, the original schedule is conflict serializable.

Points to Note: Conflict Serializability

While conflict serializability is useful, it is not the only way to ensure consistency. Some schedules might be consistent even if they are not conflict serializable. But , conflict serializability provides a clear and straightforward method for verifying consistency.

Many assume that if a schedule is not conflict serializable, it is inconsistent. This is not always true. The conflict serializability test is a filter. This helps to identify consistent schedules, but failing the test does not guarantee inconsistency.

Conclusion

In this chapter, we covered the concept of conflict serializability in DBMS and how it helps maintain database consistency. We understood the meaning of schedules, types of schedules, and when instructions are considered conflicting. We learned how to check if a non-serial schedule can be transformed into a serial one by swapping non-conflicting instructions.