Scribd
Upload
4 views6 pages

Transaction Management

Uploaded by

patilvilohith20
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
4 views6 pages

Transaction Management

Uploaded by

patilvilohith20
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

TRANSACTION MANAGEMENT

Transaction Management is a crucial


aspect of database systems that ensures
data integrity and consistency. Here’s an
overview of the key components:
1. Transactions and ACID Properties
Transactions are sequences of operations
performed as a single logical unit of
work. They ensure that a series of
operations either complete successfully
as a whole or have no effect at all.
ACID Properties are fundamental principles
that guarantee reliable processing of
database transactions:
• Atomicity: Ensures that a transaction is
treated as a single indivisible unit. Either all
operations of the transaction are executed, or
none are. If a transaction fails, it should not
affect the database.
• Consistency: Ensures that a transaction
brings the database from one consistent state
to another. It must adhere to all database
rules and constraints.
• Isolation: Ensures that transactions are
executed in isolation from each other. The
intermediate state of a transaction is invisible
to other transactions. This property is critical
to prevent concurrent transactions from
interfering with each other.
• Durability: Guarantees that once a
transaction is committed, its changes are
permanent and survive any subsequent
system failures.
2. Concurrency Control
Concurrency Control ensures that database
transactions are executed concurrently
without leading to inconsistencies. It
addresses the following issues:
• Problems of Concurrency:
o Lost Update: When two transactions
update the same data item, and one
update is lost.
o Dirty Read: When a transaction reads
data written by another uncommitted
transaction.
o Non-Repeatable Read: When a
transaction reads the same data item
twice, but the value has changed
between reads.
o Phantom Read: When a transaction
reads a set of rows that satisfies a
condition, but the set changes due to
other transactions.
• Locking Mechanisms:
o Exclusive Locks: Allow a transaction to
both read and write a data item. No
other transaction can access the locked
data.
o Shared Locks: Allow multiple transactions
to read a data item but prevent any
transaction from writing to it.
• Deadlock Handling: A situation where two or
more transactions are waiting indefinitely for
each other to release locks.
o Deadlock Prevention: Techniques to
avoid conditions that lead to deadlocks
(e.g., using a strict locking order).
o Deadlock Detection: Periodically
checking for deadlocks and taking action
(e.g., aborting one of the transactions).
o Deadlock Recovery: Techniques to
recover from a detected deadlock, such
as rolling back one of the transactions.
3. Recovery Systems
Recovery Systems are mechanisms that
ensure the database can recover from
failures and maintain ACID properties.
• Techniques for Database Recovery:
o Log-Based Recovery: Uses a log to record
all changes made by transactions. If a
failure occurs, the log is used to redo or
undo transactions to restore the
database to a consistent state.
▪ Write-Ahead Logging (WAL): Ensures
that log records are written before
the actual database changes are
applied.
▪ Undo/Redo Logs: Maintain logs of
changes to allow for both undoing
uncommitted transactions and
redoing committed transactions.
o Checkpoints: Periodic snapshots of the
database state. They simplify recovery by
reducing the amount of log data that
needs to be processed after a failure. At
recovery time, the database can be
restored from the last checkpoint and
then the log can be applied to reach the
most recent state.
These concepts are essential for ensuring
that a database remains reliable and
consistent, even in the presence of
failures and concurrent transactions.

You might also like