TRANSACTION

UNIT III TRANSACTIONS Transaction Concepts – ACID Properties – Schedules – Serializability –

Transaction support in SQL – Need for Concurrency – Concurrency control –Two Phase Locking-
Timestamp – Multiversion – Validation and Snapshot isolation– Multiple Granularity locking – Deadlock
Handling – Recovery Concepts – Recovery based on deferred and immediate update – Shadow paging –
ARIES Algorithm

DEFINITION:
When the data of users is stored in a database, that data needs to be accessed and modified from
time to time. This task should be performed with a specified set of rules and in a systematic way
to maintain the consistency and integrity of the data present in a database. In DBMS, this task is
called a transaction.
It could involve one or more database operations, such as inserting, updating, deleting, or
querying data. The concept of transactions is crucial in ensuring the integrity, consistency, and
reliability of data within a database system.
Need for transaction:
Transactions in a DBMS ensure data integrity, support concurrent access, handle errors and
recovery, execute complex operations atomically, optimize performance, and provide auditing
and compliance, making them essential for managing data reliably and consistently.
.
Eample:
a simple banking scenario where a transaction involves transferring money from one account to
another.
Suppose we have two bank accounts:
Account A with a balance of $1000.
Account B with a balance of $500.
Now, let's say a customer wants to transfer $200 from Account A to Account B. This transaction
involves two steps:
Deduct $200 from Account A.
Add $200 to Account B.
To ensure data integrity and consistency, these two steps should be treated as a single unit of
work. If either step fails, the entire transaction should be rolled back to maintain the integrity of
the accounts.
Here's how the transaction would work:
Begin Transaction: The DBMS starts the transaction.
Update Account A: Deduct $200 from Account A.
1. Update Account B: Add $200 to Account B.
2. Commit: If both updates are successful, the changes are committed to the database, and the
transaction is completed.
3. Rollback: If an error occurs during either update (e.g., insufficient funds in Account A), the
changes are rolled back, and both accounts remain unchanged.
This simple transaction ensures that the money transfer occurs atomically, maintaining the
integrity of the accounts. If any part of the transaction fails, the accounts remain in their original
state, preventing inconsistent data.
Operations of Transaction Top of Form

The operations of a transaction in a database management system typically include:

Begin Transaction: This operation marks the start of a transaction. It signifies the beginning of a
logical unit of work that may consist of one or more database operations.
Read: Transactions often involve reading data from the database to perform various operations.
Reads may involve retrieving data from one or more tables or records within the database.
Write/Update: Transactions may involve modifying or updating data within the database. This
operation includes inserting new records, updating existing records, or deleting records.
Commit: Once all the operations within the transaction have been successfully completed, the
changes made by the transaction are permanently saved to the database. The commit operation
finalizes the transaction, making its changes visible to other transactions.
Rollback: If an error occurs during the execution of a transaction or if the transaction cannot be
completed for any reason, the changes made by the transaction are undone or rolled back. This
operation ensures that the database remains in a consistent state.
Savepoint: Some database systems support savepoints, which allow a transaction to be divided
into smaller units. Savepoints provide a way to roll back to a specific point within the transaction
without necessarily rolling back the entire transaction.

The ACID properties are often associated with transactions:

Atomicity: This property ensures that a transaction is treated as a single unit of work, meaning
that either all of its operations are completed successfully, or none of them are. There's no
halfway point where some operations succeed while others fail.
Example: Consider a banking transaction where a customer transfers money from one account to
another. The atomicity property ensures that either the entire transaction of transferring funds
completes successfully or none of it happens. If the transfer is not atomic and fails midway, the
money could be deducted from one account without being added to the other, leading to
inconsistency.

Consistency: Transactions must maintain the consistency of the database. This means that the
database transitions from one consistent state to another consistent state after each transaction.
Constraints, such as foreign key constraints or unique key constraints, are upheld.
Example: Imagine a scenario where a customer wants to book a flight ticket. The database
checks whether the customer's preferred seat is available before booking. If the consistency
property is violated, the system might mistakenly book a seat that has already been reserved by
another customer, leading to an inconsistent state in the database.

Isolation: Transactions should operate independently of each other. This means that the
execution of one transaction should not affect the execution of another transaction concurrently
executing in the system. Isolation prevents interference between transactions.
Example: Suppose two users concurrently attempt to withdraw money from the same account.
Isolation ensures that the withdrawals are processed independently of each other. Without
isolation, one user's withdrawal might interfere with the other's, potentially resulting in incorrect
balances or other inconsistencies.

Durability: Once a transaction has been committed, the changes made by that transaction persist
even in the event of system failures (e.g., power loss, system crash). This ensures that the
changes are permanent and can be recovered in case of a failure.
Example: After a customer makes an online purchase, the transaction is completed, and the order
details are stored in the database. Even if there's a sudden power outage or server crash
immediately after the transaction, the durability property ensures that the order information
remains intact and is not lost. Upon system recovery, the completed transaction should still be
reflected in the database.

These properties collectively ensure that transactions are reliable and maintain the integrity of
the database, even in the presence of system failures or concurrent access by multiple users

Transaction States :
These are different types of Transaction States :
Active State –
When the instructions of the transaction are running then the transaction is in active state. If all
the ‘read and write’ operations are performed without any error then it goes to the “partially
committed state”; if any instruction fails, it goes to the “failed state”.

Partially Committed –
After completion of all the read and write operation the changes are made in main memory or
local buffer. If the changes are made permanent on the DataBase then the state will change to
“committed state” and in case of failure it will go to the “failed state”.

Failed State –
When any instruction of the transaction fails, it goes to the “failed state” or if failure occurs in
making a permanent change of data on Data Base.

Aborted State –
After having any type of failure the transaction goes from “failed state” to “aborted state” and
since in previous states, the changes are only made to local buffer or main memory and hence
these changes are deleted or rolled-back.

Committed State –
It is the state when the changes are made permanent on the Data Base and the transaction is
complete and therefore terminated in the “terminated state”.

Terminated State –
If there isn’t any roll-back or the transaction comes from the “committed state”, then the system
is consistent and ready for new transaction and the old transaction is terminated.
 Schedule
In database management systems (DBMS), schedules refer to the order in
which transactions are executed. A transaction is a logical unit of work that
consists of a series of database operations (such as reads and writes) that
should be executed together as a single unit.

There are different types of schedules in DBMS:

1. Serial Schedule: In a serial schedule, transactions are executed one after

the other without any interleaving. Each transaction is completed before the
next one begins. While this ensures consistency, it may lead to inefficiencies
as transactions are executed sequentially.
2. Concurrent Schedule: In a concurrent schedule, multiple transactions are
executed simultaneously, and their operations may interleave with each
other. This concurrency can improve system throughput and resource
utilization but requires careful management to maintain data consistency.
3. Serializable Schedule: A serializable schedule is one that produces the
same results as if the transactions were executed serially, even though they
are executed concurrently. This ensures that the execution of concurrent
transactions does not violate the consistency of the database.
4. Recoverable Schedule: A recoverable schedule ensures that if a
transaction T1 writes a data item that is subsequently read by another
transaction T2, then T1 cannot commit until T2 has committed. This prevents
the situation where T2 reads an inconsistent state of the database if T1 rolls
back.
5. Cascadeless Schedule: A cascadeless schedule ensures that if a
transaction T1 aborts, any changes made by T1 that have been read by
another transaction T2 are rolled back, preventing cascading rollback.
6. Strict Schedule: In a strict schedule, a transaction cannot read data that
has been written by another transaction that has not yet committed. This
ensures that only committed data is read, maintaining consistency.

SERIALIZABILITY
Serializability is a concept in database management systems (DBMS) that ensures
that the outcome of executing concurrent transactions is equivalent to some serial
execution of those transactions. In other words, it ensures that the interleaved
execution of transactions produces the same result as if they were executed one
after the other in some order.
Types of Serializability
There are two ways to check whether any non-serial schedule is serializable.
Types of Serializability – Conflict & View
1. Conflict serializability
Conflict serializability refers to a subset of serializability that focuses on maintaining
the consistency of a database while ensuring that identical data items are executed
in an order. In a DBMS each transaction has a value and all the transactions, in the
database rely on this uniqueness. This uniqueness ensures that no two operations
with the conflict value can occur simultaneously.
For example lets consider an order table and a customer table as two instances.
Each order is associated with one customer even though a single client may place
orders. However there are restrictions for achieving conflict serializability in the
database. Here are a few of them.
Different transactions should be used for the two procedures.
The identical data item should be present in both transactions.
Between the two operations, there should be at least one write operation.
2. View Serializability
View serializability is a kind of operation in a serializable in which each transaction
should provide some results, and these outcomes are the output of properly
sequentially executing the data item. The view serializability, in contrast to conflict
serialized, is concerned with avoiding database inconsistency. The view
serializability feature of DBMS enables users to see databases in contradictory
ways.
To further understand view serializability in DBMS, we need to understand the
schedules S1 and S2. The two transactions T1 and T2 should be used to establish
 these two schedules. Each schedule must follow the three transactions in order to
retain the equivalent of the transaction. These three circumstances are listed below.
The first prerequisite is that the same kind of transaction appears on every
schedule. This requirement means that the same kind of group of transactions
cannot appear on both schedules S1 and S2. The schedules are not equal to one
another if one schedule commits a transaction but it does not match the transaction
of the other schedule.
The second requirement is that different read or write operations should not be
used in either schedule. On the other hand, we say that two schedules are not
similar if schedule S1 has two write operations whereas schedule S2 only has one.
The number of the write operation must be the same in both schedules, however
there is no issue if the number of the read operation is different.
The second to last requirement is that there should not be a conflict between either
timetable. execution order for a single data item. Assume, for instance, that
schedule S1’s transaction is T1, and schedule S2’s transaction is T2. The data item
A is written by both the transaction T1 and the transaction T2. The schedules are
not equal in this instance. However, we referred to the schedule as equivalent to
one another if it had the same number of all write operations in the data item.

Need for Concurrency:

1. Performance Improvement: Concurrency allows programs to make better use of
available resources, such as CPU cores, by executing multiple tasks
simultaneously. This can lead to faster execution times and better overall
performance.
2. Responsiveness: Concurrency enables programs to remain responsive to user
input, even when performing intensive tasks in the background. By allowing
tasks to run concurrently, programs can continue to accept input and provide
feedback without becoming unresponsive.
3. Resource Utilization: Concurrency helps in utilizing resources efficiently. For
example, in a web server, concurrent handling of multiple requests allows
better utilization of server resources, ensuring that each request gets
processed promptly.
4. Real-time Systems: Concurrency is essential for building real-time systems
where tasks must be completed within strict timing constraints. By allowing
tasks to run concurrently, real-time systems can meet deadlines and respond
to events in a timely manner.
 TWO –PHASE LOCKING
Two-phase locking (2PL) is a concurrency control mechanism used in
database management systems (DBMS) to ensure serializability of
transactions. It consists of two phases: the growing phase and the shrinking
phase. The goal of two-phase locking is to prevent conflicts between
transactions accessing shared resources (such as database records) by
ensuring that transactions acquire and release locks in a specific order.

Here's how two-phase locking works:

1. Growing Phase:
 During the growing phase, transactions can acquire locks on resources
but cannot release any locks.
 When a transaction requests access to a resource, it must first acquire
a lock on that resource. The lock can be in various modes, such as read
lock (shared lock) or write lock (exclusive lock).
 Once a transaction acquires a lock, it can continue to acquire
additional locks on other resources but cannot release any locks it has
acquired.
2. Shrinking Phase:
 During the shrinking phase, transactions can release locks but cannot
acquire any new locks.
 After a transaction has acquired all the necessary locks it needs (in the
growing phase) and has finished accessing the resources, it can start
releasing the locks.
 Once a transaction releases a lock, it cannot acquire any new locks,
ensuring that the transaction's lock state remains unchanged.

Two-phase locking ensures that transactions follow a strict protocol for

acquiring and releasing locks, which prevents conflicts such as data
inconsistency, lost updates, and deadlock.
1. Deadlock Prevention:

 Wait-Die and Wound-Wait: These are two deadlock prevention techniques commonly used in
database systems.
 In Wait-Die, if a transaction requests a resource that is held by another transaction, it is allowed
to wait only if it has a higher priority. Otherwise, it is aborted and restarted later.
 In Wound-Wait, if a transaction requests a resource that is held by another transaction, it is
allowed to wait only if it has a lower priority. Otherwise, the transaction holding the resource is
aborted and restarted later.
 Timeouts: Set a timeout for each transaction. If a transaction cannot obtain all its required locks
within a specified time, it releases all its locks and restarts later.
 Two-Phase Locking (2PL): Enforce strict protocols for locking, ensuring that transactions
acquire all necessary locks before execution and release them only after completion. This helps
prevent circular wait conditions.

2. Deadlock Detection:
 Wait-For Graph: Maintain a wait-for graph to detect cycles that indicate deadlocks. If a cycle is
detected, the system can choose one of the transactions in the cycle to abort and release its
resources.
 Timeouts: Set timeouts for transactions. If a transaction exceeds its allocated time, it can be
aborted, and its resources released.
 Transaction Manager: Implement a transaction manager that monitors transaction behavior and
detects potential deadlocks by analyzing resource requests and utilization patterns.

These approaches aim to either prevent deadlocks from occurring in the first place or to detect
and resolve them promptly once they occur, ensuring the integrity and efficiency of the database
system. Each approach has its advantages and trade-offs, and the choice between prevention and
detection often depends on the specific requirements and constraints of the database
environment.

Timestamp Ordering Protocol:

The Timestamp Ordering Protocol is a concurrency control method used to
ensure serializability in databases. It uses timestamps to order the execution
of transactions in a way that ensures no conflicting operations violate
serializability.

Timestamps:

 Timestamp (ts): Each transaction 𝑇𝑖Ti is assigned a unique timestamp

Read Timestamp (r-timestamp): Each data item 𝑄𝑘Qk has an associated

ts(Ti) when it starts. This timestamp is used to order the transactions.


successfully read 𝑄𝑘Qk.

r-timestamp(Qk), which is the largest timestamp of any transaction that has

 Write Timestamp (w-timestamp): Each data item 𝑄𝑘Qk also has a w-

successfully written to 𝑄𝑘Qk.

timestamp(Qk), which is the largest timestamp of any transaction that has

Meaning of ts(Ti) < r-timestamp(Qk):

When a transaction 𝑇𝑖Ti requests to write to a data item 𝑄𝑘Qk, the system
checks the condition ts(Ti) < r-timestamp(Qk). Here's what this condition
signifies and how it is used:

1. Condition Explanation:

 ts(Ti) is the timestamp of transaction 𝑇𝑖Ti.

 𝑄𝑘Qk.
 r-timestamp(Qk) is the timestamp of the last transaction that successfully
read

2. Purpose:

The condition ts(Ti) < r-timestamp(Qk) checks if transaction 𝑇𝑖Ti is

attempting to write to 𝑄𝑘Qk after another transaction with a later


timestamp has already read 𝑄𝑘Qk.

3. Conflict Detection:

If ts(Ti) < r-timestamp(Qk), it means transaction 𝑇𝑖Ti is "older" than the

transaction that last read 𝑄𝑘Qk. Allowing 𝑇𝑖Ti to write to 𝑄𝑘Qk would


violate the timestamp ordering, as it would imply an out-of-order execution

relative to the read operation already performed by a "newer" transaction.

4. Action Taken:

If the condition ts(Ti) < r-timestamp(Qk) holds, the write operation by 𝑇𝑖Ti
is rejected, and 𝑇𝑖Ti is aborted and rolled back. This ensures that the


execution remains serializable, preserving the correct order of operations.

Example Scenario:

𝑇1T1 and 𝑇2T2, and

a data item 𝑄𝑘Qk:
Consider the following scenario with two transactions,

𝑇1T1 has ts(T1) = 1.

𝑇2T2 has ts(T2) = 2.


𝑇2T2 reads 𝑄𝑘Qk, setting r-timestamp(Qk)


 = 2.

If 𝑇1T1 now attempts to write to 𝑄𝑘Qk:

1. The system checks the condition ts(T1) < r-timestamp(Qk).

3. Therefore, 𝑇1T1's write operation is rejected to maintain serializability, and

2. Since ts(T1) = 1 and r-timestamp(Qk) = 2, the condition 1 < 2 is true.

𝑇1T1 is aborted.

Conclusion:
 The condition ts(Ti) < r-timestamp(Qk) is a critical part of the Timestamp
Ordering Protocol used to maintain serializability in databases. It ensures
that transactions are executed in a manner consistent with their timestamps,
preventing older transactions from overwriting data read by newer
transactions, thus preserving the correct order of operations and ensuring
data consistency.

Multiversion Two-Phase Locking

(MV2PL) is a concurrency control protocol that combines aspects of multiversion
concurrency control (MVCC) and the two-phase locking (2PL) protocol. This hybrid
approach aims to take advantage of the strengths of both methods, providing high
concurrency and ensuring serializability.

How MV2PL Works:

1. Read Operations:

When a transaction 𝑇𝑖Ti wants to read a data item 𝑄𝑘Qk, it acquires a read
lock (S-lock) on the current version of 𝑄𝑘Qk. This allows 𝑇𝑖Ti to read


without waiting for other transactions to complete, as it reads the most

recent committed version.

2. Write Operations:

When a transaction 𝑇𝑖Ti wants to write to a data item 𝑄𝑘Qk, it acquires a

write lock (X-lock). This involves creating a new version of 𝑄𝑘Qk with the


transaction's timestamp.
 Other transactions can still read the older versions, ensuring that read
operations are not blocked.

3. Commit Phase:

 During the commit phase, the transaction ensures that no other transaction
has read an older version of any data item it has written. This is where
MV2PL ensures serializability.

4. Version Maintenance:

 The system maintains multiple versions of data items. Each version has an
associated timestamp or transaction ID indicating when it was created.
 Garbage collection mechanisms periodically remove obsolete versions that
are no longer needed.
 Snapshot Isolation

(SI) is a concurrency control mechanism used in database systems to provide

a consistent view of the data to each transaction, without the need for
locking mechanisms typically associated with traditional isolation levels. It
aims to balance the trade-offs between consistency and performance,
offering a way to read and write data concurrently while maintaining a form
of isolation that avoids many common anomalies.

Key Concepts of Snapshot Isolation:

1. Consistent Snapshot:
 Each transaction operates on a snapshot of the database taken at the start of the
transaction. This snapshot remains consistent and unchanged throughout the
transaction's execution, regardless of other concurrent transactions.
Imagine an online store where customers can place orders for products. The
store's inventory is managed in a database, and two customers are making
transactions at the same time.

1. Transaction T1: Customer A is placing an order for Product X.

2. Transaction T2: Customer B is placing an order for Product Y and updating the
inventory for Product X.

Here’s how Snapshot Isolation handles these transactions to ensure

consistency.

Initial State:
 Product X: 100 units in stock
 Product Y: 50 units in stock

Transactions:

 T1: Place an order for 10 units of Product X.

 Step 1: Read the current stock of Product X.
 Step 2: Subtract 10 units from the stock.
 Step 3: Write the updated stock back to the database.
 T2: Place an order for 5 units of Product Y and update the stock of Product X
to reflect new incoming inventory.
 Step 1: Read the current stock of Product Y.
 Step 2: Subtract 5 units from the stock.
 Step 3: Write the updated stock of Product Y back to the database.
 Step 4: Read the current stock of Product X.
 Step 5: Add 50 units to the stock of Product X (reflecting new inventory received).
 Step 6: Write the updated stock of Product X back to the database.

Execution with Snapshot Isolation:

1. T1 Starts:
 Takes a snapshot of the database.
 Reads the stock of Product X: 100 units.

2. T2 Starts:
 Takes a snapshot of the database (at the same time as T1).
 Reads the stock of Product Y: 50 units.
 Reads the stock of Product X: 100 units.

3. T1 Execution:
 Subtracts 10 units from Product X's stock (100 - 10 = 90).
 Prepares to write the new stock (90 units) for Product X but does not commit yet.

4. T2 Execution:
 Subtracts 5 units from Product Y's stock (50 - 5 = 45).
 Writes the new stock for Product Y (45 units).
 Adds 50 units to Product X's stock (100 + 50 = 150).
 Prepares to write the new stock (150 units) for Product X but does not commit yet.

5. Commit Phase:
 T1 Commits: The database system checks for conflicts. Since T1 only read and
wrote Product X, and no other transactions have committed changes to Product X
since T1 started, it can safely commit. Product X now has 90 units in stock.
 T2 Commits: The database system checks for conflicts. Although T2 read Product X
and Product Y, it has updated Product X based on its own snapshot and no
conflicting writes have occurred. T2 commits, updating Product X to 150 units
(accounting for new inventory) and Product Y to 45 units.
 Final State:
 Product X: 150 units (reflecting new inventory and the subtraction of 10 units from
T1)
 Product Y: 45 units

Key Points:
1. Consistent Snapshots: Both T1 and T2 operated on consistent snapshots of the
database as of the time they started.
2. Concurrent Reads/Writes: Both transactions read and wrote data without
interfering with each other. T1's changes were based on the state of the database
before T2's changes became visible.
3. Conflict Resolution: The database system ensures that both transactions are
serializable by validating at commit time that there are no conflicts that violate
serializability.

 New Inventory: T2 added 50 units to Product A to reflect new stock

received. This is why the final state shows an increase in units for Product A.
 Subtraction of 10 Units from T1: Despite the new inventory added by T2,
the subtraction of 10 units from T1 (which committed first) is also reflected.
This means the final count for Product A includes both the decrease from T1
and the increase from T2.
 The final count of Product A is therefore:
 Initial 100 units
 Subtract 10 units (T1)
 Add 50 units (T2)
 Resulting in 150 units.

Thus, the snapshot isolation mechanism ensures that the final state of the
database is consistent and incorporates all committed changes from
concurrent transactions.