Transaction

In a DBMS, a transaction is a sequence of one or more operations

(such as reading, writing, updating, or deleting data) that are
executed as a single unit. Each transaction is a unit of both atomicity
and consistency. The concept of a transaction has been applied
broadly in database systems and applications. A transaction must
exhibit ACID properties to ensure the correctness and integrity of the
database, even in the presence of system failures or concurrent
access. A transaction can be seen as a "logical unit of work" that
should either completely succeed or completely fail, ensuring that
the database remains in a consistent state after the transaction is
completed.
A set of logically related operations is known as a transaction. The
main operations of a transaction are:
 Read(A): Read operations Read(A) or R(A) reads the value of A
from the database and stores it in a buffer in the main memory.
 Write (A): Write operation Write(A) or W(A) writes the value
back to the database from the buffer.
But it may also be possible that the transaction may fail after
executing some of its operations. The failure can be because
of hardware, software or power, etc. To avoid this, Database has
two important operations:
 Commit: After all instructions of a transaction are successfully
executed, the changes made by a transaction are made
permanent in the database.
 Rollback: If a transaction is not able to execute all operations
successfully, all the changes made by a transaction are undone.

Properties of a Transaction/ACID Properties –

To maintain consistency in a database, before and after the
transaction, certain properties are followed. These are
called ACID properties. The ACID properties, in totality, provide a
mechanism to ensure the correctness and consistency of a database
in a way such that each transaction is a group of operations that acts
as a single unit, produces consistent results, acts in isolation from
other operations, and updates that it makes are durably stored.

Atomicity:
By this, we mean that either the entire transaction takes place at
once or doesn’t happen at all. There is no midway i.e. transactions do
not occur partially. Each transaction is considered as one unit and
either runs to completion or is not executed at all. It involves the
following two operations.
Abort: If a transaction aborts, changes made to the database are not
visible.
Commit: If a transaction commits, changes made are visible.
Atomicity is also known as the ‘All or nothing rule’.
Example: If a transaction involves transferring money from Account A
to Account B, both the debit from Account A and the credit to
Account B must succeed. If one operation fails, neither operation
should take effect.
Consistency:
This means that integrity constraints must be maintained so that the
database is consistent before and after the transaction. It refers to
the correctness of a database. This means that integrity constraints
must be maintained so that the database is consistent before and
after the transaction. It refers to the correctness of a database.
Example: A transaction should not leave the database in an
inconsistent state, where business rules or integrity constraints are
violated.

Isolation:
ensures that the operations of one transaction are not visible to
other transactions until the transaction is complete. Even though
transactions may execute concurrently, the intermediate states of a
transaction are not seen by others, preventing issues like "dirty
reads," "non-repeatable reads," and "phantom reads."
Example: If two users are concurrently accessing the same data, the
database ensures that one user's transaction does not interfere with
the other's, even if both are working with the same records.

Durability
Durability ensures the permanency of something. It ensures that the
data after the successful execution of the operation becomes
permanent in the database. The durability of the data should be so
perfect that even if the system fails or leads to a crash, the database
still survives. The database must ensure that the results of a
committed transaction are not lost.
Example: After a bank transfer transaction is committed, the changes
(like the updated balance in both accounts) will survive system
crashes and will be recoverable when the system is restored.

Advantages of ACID Properties in DBMS

1. Data Consistency: ACID properties ensure that the data remains
consistent and accurate after any transaction execution.
2. Data Integrity: ACID properties maintain the integrity of the
data by ensuring that any changes to the database are
permanent and cannot be lost.
3. Concurrency Control: ACID properties help to manage multiple
transactions occurring concurrently by preventing interference
between them.
4. Recovery: ACID properties ensure that in case of any failure or
crash, the system can recover the data up to the point of failure
or crash.
Disadvantages of ACID Properties in DBMS
 1. Performance: can cause a performance overhead in the
system, as they require additional processing to ensure data
consistency and integrity.
2. Scalability: may cause scalability issues in large distributed
systems where multiple transactions occur concurrently.
3. Complexity: Implementing the ACID properties can increase the
complexity of the system and require significant expertise and
resources.

Transaction States
A transaction passes through several states during its lifetime:
1. Active: The transaction is being executed, and operations are
being performed.
2. Partially Committed: The transaction has completed its final
operation but has not yet been committed to the database.
3. Committed: The transaction has successfully completed all its
operations and changes are permanently saved to the
database.
4. Failed: The transaction could not complete due to some error,
and it will need to be rolled back.
5. Rolled Back: In case of a failure, the transaction is undone, and
the database is restored to its state before the transaction
began.
Examples of Transactions
1. Bank Transfer:
o Suppose a customer wants to transfer money from their
savings account to their checking account. The transaction
involves two main steps:
 Debit the savings account.
 Credit the checking account.
o If either of these operations fails (e.g., due to insufficient
funds or a system crash), the entire transaction must be
rolled back to avoid inconsistent states.
2. Online Shopping:
o In an online shopping system, a transaction may involve
selecting items, applying discounts, updating inventory,
and charging the customer. If any step fails (e.g., payment
failure), the entire transaction should fail, and no partial
changes (like reduced stock) should be saved.

Concurrency Control
Concurrency control in a DBMS refers to the mechanisms used to
ensure that multiple transactions can be executed concurrently
(multiple users can access and use the same database at one time,
which is known as the concurrent execution) without violating the
ACID properties. Specifically, concurrency control primarily focuses
on the Isolation property, which ensures that the operations of one
transaction are isolated from those of other concurrent transactions.
This is essential in multi-user environments where many users’
accesses and modify the database simultaneously.
The thing is that the simultaneous execution that is performed
should be done in an interleaved manner, and no operation should
affect the other executing operations, thus maintaining the
consistency of database.
Concurrency Control Problems
In a database transaction, the two main operations
are READ and WRITE operations. So, there is a need to manage these
two operations in the concurrent execution if these operations are
not performed in an interleaved manner, and the data may become
inconsistent.
1 Lost Update:
 Occurs when two transactions read the same data and update it
based on the read value. One of the updates is lost when the
other transaction overwrites it.
 Example: Two bank customers both try to withdraw money
from the same account. One transaction overwrites the other’s
update, leading to a lost transaction.
2 Dirty Read:
 A transaction reads data that has been modified by another
transaction but has not yet been committed. If the second
 transaction is rolled back, the first transaction has read invalid
data.
 Example: A transaction reads a price that is being updated, but
before the update is committed, the transaction reads the
uncommitted value. If the update is rolled back, the transaction
has used incorrect data.
3 Non-Repeatable Read:
 A transaction reads the same data twice but gets different
results due to another transaction modifying the data between
the reads.
 Example: A transaction reads a customer’s account balance, but
before it reads it again, another transaction updates the
balance. The two reads yield different results, causing
inconsistency.

Concurrency Control Protocols

The concurrency control protocols ensure the atomicity, consistency,
isolation, durability and serializability of the concurrent execution of
the database transactions. Therefore, these protocols are categorized
as:
o Lock Based Concurrency Control Protocol
o Time Stamp Concurrency Control Protocol

Lock Based Concurrency

ensure data consistency and integrity when multiple transactions
are executed concurrently. It involves the use of locks to control
access to data items, preventing conflicts like dirty reads, lost
updates, and non-repeatable reads. By regulating how
transactions can access and modify shared data, lock-based
concurrency control ensures that transactions behave as if they
were executed serially, preserving the properties, particularly
Isolation. This ensures that transactions are executed without
violating database consistency.

Types of Locks:
1. Shared lock:
o It is also known as a Read-only lock. In a shared lock, the data
item can only read by the transaction.
o It can be shared between the transactions because when the
transaction holds a lock, then it can't update the data on the
data item.
Example: If two transactions T1 and T2 both want to read the
same data item, both can acquire a shared lock and read the data.
However, no transaction can modify the data while it holds a
shared lock.
2. Exclusive lock:
o In the exclusive lock, the data item can be both reads as well as
written by the transaction.
o This lock is exclusive, and in this lock, multiple transactions do
not modify the same data simultaneously, ensuring that no
other transaction can read or modify it.
Example: If transaction T1 has an exclusive lock on a data item,
transaction T2 cannot read or modify that data item until T1
releases the lock.

Types of Lock-Based Protocols

1. Simplistic Lock Protocol
It is the simplest method for locking data during a transaction.
Simple lock-based protocols enable all transactions to obtain a
lock on the data before inserting, deleting, or updating it. It will
unlock the data item once the transaction is completed.
2. Pre-claiming Lock Protocol
o Pre-claiming Lock Protocols evaluate the transaction to list all
the data items on which they need locks.
o Before initiating an execution of the transaction, it requests
DBMS for all the lock on all those data items.
o If all the locks are granted then this protocol allows the
transaction to begin. When the transaction is completed then it
releases all the lock.
o If all the locks are not granted then this protocol allows the
transaction to rolls back and waits until all the locks are
granted.

3. Two-phase locking (2PL)

Two-Phase Locking (2PL) is a widely used locking protocol in a
DBMS to ensure serializability It is a concurrency control
method that regulates how transactions acquire and release
locks on data items during their execution to maintain
consistency and avoid conflicts like dirty reads, lost updates,
and non-repeatable reads. 2PL plays a vital role in transaction
management by ensuring that transactions execute in a
 manner that guarantees correctness, consistency, and isolation,
thus preserving the ACID properties.
o The two-phase locking protocol divides the execution phase of
the transaction into three parts.
o In the first part, when the execution of the transaction starts, it
seeks permission for the lock it requires.
o In the second part, the transaction acquires all the locks. The
third phase is started as soon as the transaction releases its first
lock.
o In the third phase, the transaction cannot demand any new
locks. It only releases the acquired locks.

There are two phases of 2PL:

Growing phase: In the growing phase, a new lock on the data item
may be acquired by the transaction, but none can be released.
Shrinking phase: In the shrinking phase, existing lock held by the
transaction may be released, but no new locks can be acquired.
The following way shows how unlocking and locking work with 2-PL.

Transaction T1:
o Growing phase: from step 1-3
o Shrinking phase: from step 5-7
o Lock point: at 3
Transaction T2:
o Growing phase: from step 2-6
o Shrinking phase: from step 8-9
o Lock point: at 6
Lock Point: The Point at which the growing phase ends, i.e.,
when a transaction takes the final lock, it needs to carry on its
work.

How Two-Phase Locking Ensures

Serializability:
The main goal of Two-Phase Locking is to ensure
serializability, which is the highest level of transaction
isolation. Serializability ensures that the result of
executing multiple transactions concurrently is the
same as if they were executed sequentially, one after
another.
 Locking and Serializability:
In 2PL, by acquiring locks in the growing phase
and releasing them only in the shrinking phase,
the protocol guarantees that the transactions do
not interfere with each other in conflicting ways.
The order in which locks are acquired and released
ensures that transactions can be serially ordered.
 Conflict Resolution:
2PL guarantees that there is no cycle in the wait-
for graph (the graph that tracks which
transactions are waiting for locks). Since each
transaction releases locks only in the shrinking
phase, and once it starts releasing locks it cannot
acquire any new ones, 2PL prevents cyclic
dependencies that could lead to deadlocks.

Benefits of Two-Phase Locking for

Transaction Management
1. Guarantees Serializability
2. Prevents Conflicts
3. Supports Concurrent Transaction Execution
4. Easy to Implement

Deadlock in Lock-Based Concurrency Control

A deadlock is a condition where two or more
transactions are waiting indefinitely for one another to
give up locks. Deadlock is said to be one of the most
feared complications in DBMS as no task ever gets
finished and is in waiting state forever.
example: In the student table, transaction T1 holds a
lock on some rows and needs to update some rows in
the grade table. Simultaneously, transaction T2 holds
locks on some rows in the grade table and needs to
update the rows in the student table held by
Transaction T1. Now Transaction T1 is waiting for T2 to
release its lock and similarly, transaction T2 is waiting
for T1 to release its lock. All activities come to a halt
state and remain at a standstill. It will remain in a
standstill until the DBMS detects the deadlock and
aborts one of the transactions.

Deadlock Prevention and Detection

1. Deadlock Prevention:
o Preventing deadlocks involves ensuring that
at least one of the following conditions does
not hold:
o Mutual Exclusion:
o At least one resource (like a lock on a data
item) must be held in a non-shareable mode.
In other words, only one transaction can use
the resource at any given time.
o Hold and Wait:
o A transaction is holding at least one resource
and is waiting to acquire additional resources
that are currently being held by other
transactions.
o No Pre-emption:
o Once a transaction has acquired a resource
(e.g., a lock), it cannot be forcibly taken away
from it. The transaction must release it
voluntarily.
o Circular Wait:
o A set of transactions exist such that each
transaction is waiting for a resource held by
 the next transaction in the set. This forms a
cycle or loop.
o A common method of deadlock prevention is
to use timeouts or ordering protocols,
where transactions must acquire locks in a
predefined order.
Deadlock Detection:
o In deadlock detection, the DBMS periodically
checks for cycles in the wait-for graph (a
graph representing which transaction is
waiting for
o which).
o If a cycle is detected, one of the transactions
in the cycle is rolled back to break the
deadlock.

Deadlocks Impact the System

Delays: Transactions can't finish their operations.
Resource Wastage: Locks on data items are not released, which
could block other transactions.
System Performance Decrease: If many deadlocks occur, the overall
throughput of the database reduces.
Limitations of Two-Phase Locking
1. Deadlock Risk
2. Reduced Concurrency
3. Overhead

4. Strict Two-phase locking (Strict-2PL) (optional)

o The first phase of Strict-2PL is similar to 2PL. In the first phase,
after acquiring all the locks, the transaction continues to
execute normally.
 o The only difference between 2PL and strict 2PL is that Strict-2PL
does not release a lock after using it.
o Strict-2PL waits until the whole transaction to commit, and then
it releases all the locks at a time.
o Strict-2PL protocol does not have shrinking phase of lock
release.

Timestamp Ordering Protocol

o The Timestamp Ordering Protocol is used to order the
transactions based on their Timestamps. The order of
transaction is nothing but the ascending order of the
transaction creation.
o The priority of the older transaction is higher that's why it
executes first. To determine the timestamp of the transaction,
this protocol uses system time or logical counter.
o The lock-based protocol is used to manage the order between
conflicting pairs among transactions at the execution time. But
Timestamp based protocols start working as soon as a
transaction is created.
o Let's assume there are two transactions T1 and T2. Suppose the
transaction T1 has entered the system at 007 times and
transaction T2 has entered the system at 009 times. T1 has the
higher priority, so it executes first as it is entered the system
first.
 o The timestamp ordering protocol also maintains the timestamp
of last 'read' and 'write' operation on a data.
To ensure this, use two Timestamp Values relating to each
database item X.
 W_TS(X) is the largest timestamp of any transaction that
executed write(X) successfully.
 R_TS(X) is the largest timestamp of any transaction that
executed read(X) successfully.

Advantages and Disadvantages of TO protocol:

o TO protocol ensures serializability since the precedence graph is
as follows:

o TS protocol ensures freedom from deadlock that means no

transaction ever waits.
o But the schedule may not be recoverable and may not even be
cascade- free.
Disadvantages of Timestamp Ordering Protocol
 Limited Granularity: This can lead to situations where
transactions are unnecessarily blocked, even if they do not
conflict with each other.
 Timestamp Ordering: In order to ensure that transactions are
executed in the correct order, the timestamps need to be
carefully managed.
 Timestamp Synchronization: Timestamp-based concurrency
control requires that all transactions have synchronized clocks.
If the clocks are not synchronized, it can lead to incorrect
ordering of transactions.