Table of contents

Introduction

What is Dirty Reads?

2.1.

The Problem with Dirty Reads

2.2.

Avoiding Dirty Reads

Dirty Read Problem Example

Example: Overcome the Dirty Read Concurrency Problem

Frequently Asked Questions

5.1.

What is a dirty read in DBMS?

5.2.

Why are dirty reads problematic?

5.3.

How can you prevent dirty reads?

Conclusion

Last Updated: Feb 5, 2025

Dirty Read Problem in DBMS

Author Ravi Khorwal

Introduction

Working with databases can sometimes be tricky, especially when it comes to handling transactions. One common issue that arises is the "dirty read" problem. A dirty read occurs when a transaction reads data written by a concurrent uncommitted transaction.

This article will help you understand what dirty reads are, why they can be a problem, and how to prevent them.

What is Dirty Reads?

To understand dirty reads, we first need to understand the concept of a transaction. A transaction is a sequence of operations performed as a single logical unit of work. A transaction must be atomic – it must either be fully completed or not executed at all.

A dirty read happens when a transaction reads data that has been written by another running transaction and that data is subsequently rolled back. As a result, the first transaction ends up reading data that technically doesn't exist.

Consider the following sequence of operations:

Time 1: Transaction T1 modifies row R

Time 2: Transaction T2 reads row R

Time 3: Transaction T1 aborts, and the changes to row R are rolled back

In this scenario, at Time 2, transaction T2 read uncommitted data from transaction T1, and that data was later rolled back. This is a classic example of a dirty read.

The Problem with Dirty Reads

The issue with dirty reads is that they can lead to inaccurate results and inconsistencies in the database. Since a dirty read accesses data that's not yet committed, it could end up reading temporary, unconfirmed data. If the transaction that modifies the data aborts and the changes are rolled back, then the transaction that performed the dirty read will have read data that no longer exists. This can lead to all sorts of confusion and inconsistencies.

Avoiding Dirty Reads

To prevent dirty reads, most DBMS use isolation levels, a concept in the DBMS that controls how and when the changes made by one transaction are visible to others. There are four levels of isolation: Read Uncommitted, Read Committed, Repeatable Read, and Serializable. Each level provides a stronger guarantee of isolation than the level before it.

To avoid dirty reads, you need to use an isolation level of Read Committed or higher. Read Committed is the default isolation level in many databases, and it ensures that a transaction only sees changes that have been committed before it began.

In SQL, you can set the isolation level of a transaction like this:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

With this isolation level set, the DBMS ensures that your transaction will not read uncommitted data from other transactions.

Dirty Read Problem Example

Consider two people, X and Y, who are trying to book a train ticket from IRCTC. Let's suppose they perform the below sequence of events:

Time	X	Y
T1	READ(SEATS)	…..
T2	SEATS=SEATS-1	…..
T3	WRITE(SEATS)	…..
T4	….	READ(SEATS)
T5	….	COMMIT
T6	ROLLBACK	…..

Now, let’s say before X and Y started the booking process, 4 seats were available. Then X came and read SEATS as 4, then he starts the booking process, and therefore he decreased the value of SEATS to 3.
Now, Y came and read the count of seats i.e. SEATS, to be 3. But after some time, A’s transaction got ROLLBACK. Then the value of SEATS will get updated to its starting value i.e. 4. Therefore, we can say Y has read a Dirty value of SEATS.

Example: Overcome the Dirty Read Concurrency Problem

Concurrency control protocols that we can implement to overcome the Dirty read problem with other concurrency problems which can arise are as follows:

Time-Based Protocols: According to this protocol, each transaction has a timestamp attached to it. The timestamp is dependent on the time in which the transaction is entered into the system. Every transaction has read and write timestamps, which contain the timestamps of the most recent read and write operations, respectively.
Validation-Based Protocols: In this, we have some phases like the Validation phase, Reading phase, and Validation test phase. During each of these phases, we undergo certain commands to ensure that the Dirty Read problem should not occur.
Lock-Based Protocols: To achieve consistency, the most essential tool is the isolation between the transactions. Isolation is accomplished if we disable the transaction to carry out a read/write operation. This is known as locking an operation in a transaction. Desired operations are freely permitted to conduct locking the unwanted actions through lock-based protocols.

Also read - multiple granularity in dbms

Frequently Asked Questions

What is a dirty read in DBMS?

A dirty read occurs when a transaction reads data from another running transaction that hasn't yet committed its changes.

Why are dirty reads problematic?

Dirty reads can lead to inconsistencies and inaccurate results because they might access temporary data that could later be rolled back.

How can you prevent dirty reads?

To prevent dirty reads, use an isolation level of Read Committed or higher in your transactions.

Conclusion

Understanding how transactions work and the problems that can occur, like dirty reads, is crucial when working with a DBMS. By carefully choosing the appropriate isolation level for your transactions, you can avoid dirty reads and maintain the integrity of your data. Remember, preventing dirty reads is not just about getting accurate results; it's about ensuring the reliability of your entire database system. So, be cautious, be aware, and always make sure your database operations are safe and sound. Happy database managing!