Transaction Management in Database Management System

Transaction Management
16-Apr-24 Christalin Nelson | SOCS
1 of 26

At a Glance
• Introduction to Transaction Processing (TP)
• Transaction and System Concepts
• Desirable Properties of Transactions
• Characterizing Schedules based on Recoverability
• Characterizing Schedules based on Serializability
16-Apr-24
Christalin Nelson | SOCS
2 of 26

16-Apr-24
Introduction to Transaction Processing (1/7)
• Single vs. Multiple User
– Classification of DB system based on the number of concurrent users
– Multi-User
• Multiprogramming OS facilitates Concurrent access
• Interleaved processing Vs. Parallel processing of concurrent transactions (refer fig.)
3 of 26

16-Apr-24
• Transaction processing (TP) systems
– Systems with large databases & 100s of concurrent users executing DB transactions
– Require high availability, Fast response time
• Transaction
– Logical atomic unit of DB processing that is implemented by a computer program
• Either all operations in a Transaction are committed or aborted
– It includes a few DB access operations (retrievals, insertions, deletions, and updates)
• Specified interactively via a high-level query language like SQL (OR)
• Embedded within an application program
– Application programs can contain several transactions separated by Transaction boundaries
» Transaction boundaries: Begin and End of transaction
– Can be Read-Only (or) Read-Write
4 of 26

16-Apr-24
• Data Item (X)
– Database is represented as a collection of named data items that could be
• Larger unit (like whole disk block)
– Here, Disk block address can be considered as the name of a data item that uniquely identifies it
• Database record, or
• Smaller unit (like a field/attribute of some record)
• Granularity (Size of a data item)
• Basic unit of data transfer (Disk  Buffer in Main memory): 1 Block
– Buffer replacement policy
5 of 26

16-Apr-24
• Basic database access operations
– Assume: Data item & program variable are given the same name X
– read_item(X)
• Reads value of DB item (X) into a program variable (X)
– Find address of Disk block that contains item X  Copy Disk block into a buffer in main memory
(if unavailable)  Copy item X from buffer to program variable (X)
– write_item(X)
• Writes value of program variable (X) into DB item (X)
– Find address of Disk block that contains DB item (X)  Copy Disk block into a buffer in main
memory (if unavailable)  Copy program variable (X) into the correct location of DB item (X) in
buffer  Store updated block from buffer back to disk (immediately or later point in time)
» Time to perform update: Handled together by Recovery manager of DBMS & underlying OS
– Note: Read-Set {X, Y}, Write-Set (X, Y}
6 of 26

16-Apr-24
• Sample Transactions on Bank DB
– Transaction T1 performs fund transfer (N) from account X to Y
– Transaction T2 performs a deposit (M) to account X
7 of 26

16-Apr-24
• Need for Concurrency Control
– Lost Update Problem
• Transactions T1 (update DB item X) and T2 (read X) are submitted at approx. same time &
their operations are interleaved. T2 reads X before T1. Hence, the update from T1 is lost.
– Temporary Update (or Dirty Read) Problem
• Transaction T1 updates a DB item X and then fails for some reason. The updated X is read
by transaction T2 before X is changed back to its original value.
– Incorrect Summary Problem
• Transaction calculates an aggregate summary function on some records while other
transactions update a few of these records. The aggregate function may calculate some
values before they are updated and others after they are updated.
– Unrepeatable Read Problem
• Transaction T1 reads the same item (X) twice. X is changed by transaction T2 between the
two reads of T1. Hence, T1 receives different values for its two reads of same X.
8 of 26

16-Apr-24
• Need for Recovery
– During TP, all operations in a Transaction (atomic unit) are committed or aborted
Types
of
Failures
Computer Failure (System
Crash)
Hardware (Memory), Software,
or Network error
Transaction Error (System
Error)
Operation (like integer overflow or division by zero),
Erroneous parameter values, Bugs, User interrupts
Local errors or Exception
conditions detected
E.g. Data not found
Concurrency control
enforcement
Serializability violations,
Deadlocks
Disk failure
R/W malfunction, Disk R/W
head crash
Physical problems and
catastrophes
Power or AC failure, fire, theft, sabotage,
overwriting by mistake, mounting wrong tape
Cases 1-4 are common &
Recovery time is much faster
when compared to Cases 5 &
6 which are rare & serious
9 of 26

16-Apr-24
Transaction and System Concepts (1/5)
• Transaction States and Additional Operations (1/2)
– All operations in a Transaction (atomic unit) are committed or aborted
– Operations that the Recovery manager of DBMS should track
• BEGIN_TRANSACTION
• READ
• WRITE
• END_TRANSACTION
• COMMIT_TRANSACTION – Committed operations cannot be undone
• ROLLBACK (or ABORT) – All operations in a transaction need to be undone
– Recovery Techniques use
• Undo (on single operation)
• Redo (on single operation)
10 of 26

16-Apr-24
• Transaction States and Additional Operations (2/2)
– State Transition Diagram
• States for Transaction execution
11 of 26

16-Apr-24
• System Log (1/2)
– Sequential, append-only file stored on disk which is used to recover from failures
• Not affected by any type of failure (Except disk failure or catastrophic failure)
– Keeps track of all transaction operations and other transaction information
– Log entries (or log records) are added to Main memory buffer  Append Log buffer to
Log file on disk (when buffer is full or when certain other conditions occur)
– Periodically backed up on tape to guard against catastrophic failures
– Types of entries
• [start_transaction, T]
• [write_item, T, X, old_value, new_value]
• [read_item, T, X]
• [commit, T]
• [abort, T]
T - Transaction-id (auto-generated)
X - DB item
12 of 26

16-Apr-24
• System Log (2/2)
– Variations
• Recovery protocols that avoid cascading rollbacks do not require READ operations to be
written in System Log
• Few recovery protocols require WRITE entries with either new_value or old_value (instead
of both)
• Could include entries relevant to other uses of Log (like auditing)
13 of 26

16-Apr-24
• Commit Point of a Transaction
– All operations of transaction (T) are executed successfully  Log the effect of all DB
operation of T  Force-write any portion of Log that was not written to Disk  T has
reached the Commit Point  T has committed & all changes in recorded permanently
in DB  Now, T writes a commit record [commit, T] into Log.
– Rollback on system failure
• Refer Log File in Disk  Find Transaction T that has written a [start_transaction, T] record in
the Log but has not written its [commit, T] record  Rollback such transactions
14 of 26

16-Apr-24
Desirable Properties of Transactions
• ACID properties
Atomicity – Transaction is an atomic unit - performed entirely or not at
all
A
Consistency Preservation – Fully executed without interference – takes
DB from one consistent state to another (Start & End of transaction)
C
Isolation – Execution of a transaction should not be interfered with by
any other transactions executing concurrently
I
Durability – DB changes by a committed transaction must persist & not
be lost because of any failure
D
Isolation levels
Level 0 - Does not overwrite dirty reads of higher-level transactions
Level 1 - No lost updates
Level 2 - No lost updates, No dirty reads
Level 3 - (True isolation) No lost update, No dirty reads, repeatable reads
Transaction Recovery
subsystem
Responsibility of
Programmers
Concurrency Control
subsystem
Transaction Recovery
subsystem
15 of 26

16-Apr-24
Characterizing Schedules Based on Recoverability (1/8)
• Schedule (or history) of Transaction (1/5)
– Order of execution of operations from various transactions executing concurrently in
an interleaved fashion. It preserves the order of operations inside each transaction.
– Also called as Total ordering
– The notation used to represent operations in Schedule
• begin_transaction - b
• end_transaction - e
• read_item - r
• write_item - w
• commit - c
• abort - a
• transaction id - subscript of each operation
• DB item X - Follows r and w operations in parentheses
16 of 26

16-Apr-24
– Example
17 of 26

16-Apr-24
– Conditions satisfied by Conflicting operations in a schedule:
• (1) They belong to different transactions
• (2) They access the same item X and
• (3) At least one of the operations is a write_item(X)
• (4) Change of order can result in a different outcome
– Read-Write conflict
– Write-Write conflict
18 of 26

16-Apr-24
– Example: In schedule
• Conflicting operations
– r1(X) and w2(X)
– r2(X) and w1(X)
– w1(X) and w2(X)
– Read-Write Conflict: Order change from r1(X); w2(X) to w2(X); r1(X)
– Write-Write Conflict: Order change from w1(X); w2(X) to w2(X); w1(X)
• Non-conflicting operations
– r1(X) and r2(X) – Both are read operations
– w2(X) and w1(Y) – They operate on distinct data items X and Y
– r1(X) and w1(X) – They belong to the same transaction
19 of 26

16-Apr-24
– Conditions satisfied by Complete Schedule (S) of ‘n’ transactions T1, T2, ..., Tn
• (1) All operations in the transactions must appear in S, including a commit or abort
operation as the last operation for each transaction in S
• (2) For any pair of operations from same transaction Ti, their relative order of appearance
in S is the same as their order of appearance in Ti. Total order must be specified.
• (3) For any two conflicting operations, one of two must occur before the other in S. Total
order must be specified.
– Partial Order
• Two non-conflicting operations can occur in the Schedule without defining which occurs
first. Hence, S is considered as a partial order of operations in n transactions
– Committed projection C(S) of a schedule S
• S includes only the operations that belong to committed transactions.
20 of 26

16-Apr-24
• Recoverable schedule
– Criterion: Once transaction T is committed, it should never be necessary to roll back T.
– Examples: Sa is a partial Schedule (does not include “commit”)
• Non-recoverable schedule
– Example: T2 reads X after T1 has written X. But T2 commits before T1 and T1 aborts
later.
• Sd is a modification of Sc. Sd is recoverable.
21 of 26

16-Apr-24
• Cascading rollback (or cascading abort)
– Criterion: An uncommitted transaction has to be rolled back because it read an item
from a transaction that failed
– Example:
• Here, T2 has to be rolled back because it read item X from T1, and T1 then aborted
• Cascadeless Schedule (Schedule that avoids cascading rollback)
– Criterion: Every transaction in the schedule reads only items that were written by
committed transactions.
– Example: r2(X) in Sd and Se must be postponed until after T1 has committed (or
aborted), thus delaying T2 but ensuring no cascading rollback if T1 aborts.
22 of 26

16-Apr-24
• Strict Schedule
– Criterion: Transactions can neither read nor write an item X until the last transaction
that wrote X has committed (or aborted)
– All Strict schedules are Cascadeless, and all Cascadeless schedules are recoverable
23 of 26

16-Apr-24
Characterizing Schedules Based on Serializability (1/2)
• Serial Schedule: A schedule S is serial if, for every transaction T participating in S,
all the operations of T are executed sequentially in S. Otherwise, the schedule is
called a Non-serial schedule.
• Serializable Schedule: A schedule S is serializable if it is equivalent to some serial
schedule of the same n transactions and interleaving is possible.
Serializable schedule
(T1 & T2 is interleaved)
Serial schedules
(T1 & T2 is not interleaved)
24 of 26

16-Apr-24
Characterizing Schedules Based on Serializability (2/2)
• Result equivalent
– Two schedules are called result equivalent if they produce same final state of database
• Conflict equivalent
– Two schedules are said to be conflict equivalent if the order of any two conflicting
operations is the same in both schedules
• Conflict serializable
– A schedule S is said to be conflict serializable if it is conflict equivalent to some serial
schedule S’
Two schedules that are result equivalent for initial value
of X = 100 but are not result equivalent in general
25 of 26

Thank You
16-Apr-24
16-Apr-24
26 of 26

Transaction Management in Database Management System

More Related Content

What's hot (20)

Similar to Transaction Management in Database Management System (20)

More from Christalin Nelson (18)

Recently uploaded (20)

Transaction Management in Database Management System