Professional Documents
Culture Documents
Transaction Management
Transaction Management
Transaction Management
TRANSACTION MANAGEMENT
A transaction usually means that the data in the database has changed.
One of the major uses of DBMS is to protect the user’s data from system
failures.
Transaction Start.
Insert your ATM card.
Select a language for your transaction.
Select the Savings Account option.
Enter the amount you want to withdraw.
Enter your secret pin.
Wait for some time for processing.
Collect your Cash.
Transaction Completed.
Transaction
Concepts
• A transaction can include the following basic database access
operation.
• Read/Access data (R): Accessing the database item from disk (where the
database stored data) to memory variable.
• Write/Change data (W): Write the data item from the memory variable
to the disk.
6. write(B)
Transaction and System Concepts
(cont’d.)
Figure 20.4 State transition diagram illustrating the states for transaction execution
Transaction
States
• ACTIVE - It is the initial state. A transaction will be in active
state while it is executing its instructions.
• ABORTED - When a transaction has been rolled back, and the database
has been returned to how it was before the execution began, the
transaction is said to be in an Aborted state.
• A - Atomicity:
• Definition: Transactions are treated as atomic
units, meaning they either succeed entirely or
fail entirely.
• C- Consistency:
• Definition: Ensures that the database remains
in a consistent state before and after the
transaction.
Introduction to Transaction
Processing Concepts and Theory
(Textbook 1)
20.1 Introduction to
Transaction Processing
• This section, we have to discuss the concepts of
concurrent execution of transactions and recovery from
transaction failures.
Single-user DBMS
At most one user at a time can use the system
Example: home computer
Multiuser DBMS
Many users can access the system (database) concurrently.
write_item(X)
Writes the value of program variable X into the database item
named X
Process includes finding the address of the disk block, copying to
and from a memory buffer, and storing the updated disk block back
to disk
Read and Write Operations
(cont’d.)
Read set of a transaction
Set of all items read
Write set of a transaction
Set of all items written
For example, if X = 80 at the start (originally there were 80 reservations on the flight), N
= 5 (T1 transfers 5 seat reservations from the flight corresponding to X to the flight
corresponding to Y), and M = 4 (T2 reserves 4 seats on X), the final result should be X =
79.
However, in the interleaving of operations shown in Figure 20.3(a), it is X = 84 because
the update in T1 that removed the five seats from X was lost.
Figure 20.3 (cont’d.) Some problems that occur when concurrent execution is
uncontrolled (b) The temporary update problem
3. The Incorrect Summary
Problem
For example, suppose that a transaction T3 is calculating the
total number of reservations on all the flights;
Figure 20.3 (cont’d.) Some problems that occur when concurrent execution
is uncontrolled (c) The incorrect summary problem
4. The Unrepeatable Read
Problem
Transaction T reads the same item twice
Value is changed by another transaction T′
between the two reads
T receives different values for the two reads of
the same item
Why Recovery is
Needed
Committed transaction
Effect recorded permanently in the database
Aborted transaction
Does not affect the database
Types of transaction failures
Computer failure (system crash)
Transaction or system error
Local errors or exception conditions detected by
the transaction
Why Recovery is Needed
(cont’d.)
Types of transaction failures (cont’d.)
Concurrency control enforcement
Disk failure
Physical problems or catastrophes
System must keep sufficient information to
recover quickly from the failure
Disk failure or other catastrophes have long
recovery times
-----END-----
LECTURE-3
CHAPTER 20
20.2 Transaction and System
Concepts
20.2 Transaction and System
Concepts
For recovery purposes, the system needs to
keep track of when each transaction starts,
terminates, and commits, or aborts.
ACID properties
Atomicity
Transaction performed in its entirety or not at all
Consistency preservation
Takes database from one consistent state to
another
Isolation
Not interfered with by other transactions
Durability or permanency
Changes must persist in the database
Isolation: A transaction should appear as though it is being
executed in isolation from other transactions, even though many
transactions are executing concurrently. That is, the execution of a
transaction should not be interfered with by any other transactions
executing concurrently.
Levels of isolation
Level 0 isolation does not overwrite the dirty reads
of higher-level transactions
Level 1 isolation has no lost updates
Level 2 isolation has no lost updates and no dirty
reads
Level 3 (true) isolation has repeatable reads
In addition to level 2 properties
Snapshot isolation
20.4 Characterizing Schedules
Based on Recoverability
Schedule or history (S)
Order of execution of operations from all
transactions (Ti)
Operations from different transactions can be
interleaved in the schedule
Total ordering of operations in a schedule
For any two operations in the schedule, one must
occur before the other
20.4 Characterizing Schedules
Based on Recoverability
Read-write conflict
Write-write conflict
For example, in schedule Sa, the operations r1(X)
and w2(X) conflict, as do the operations r2(X) and
w1(X), and the operations w1(X) and w2(X).
However, the operations r1(X) and r2(X) do not
conflict, since they are both read operations.
Read-write conflict
Ex. r1(X); w2(X) to w2(X); r1(X)
Write-write conflict
Ex. w1(X); w2(X) to w2(X); w1(X).
It is important to characterize the types of schedules for
which recovery is possible for failed transaction, as well as
those for which recovery is relatively simple.
1. Recoverable schedules
Recovery is possible for committed transaction
Serializable schedules
Always considered to be correct when concurrent
transactions are executing
Places simultaneous transactions in series
Transaction T1 before T2, or vice versa
Figure 20.5 Examples of serial and nonserial schedules involving transactions T1
and T2 (a) Serial schedule A: T1 followed by T2 (b) Serial schedule B: T2 followed
by T1 (c) Two nonserial schedules C and D with interleaving of operations
Problem with serial schedules
Limit concurrency by prohibiting interleaving of
operations
Unacceptable in practice
Solution: determine which schedules are
equivalent to a serial schedule and allow those to
occur
Serializable schedule of n transactions
Equivalent to some serial schedule of same n
transactions
Result equivalent schedules
Produce the same final state of the database
May be accidental
Cannot be used alone to define equivalence of
schedules
Figure 20.6 Two schedules that are result equivalent for the initial value
of X = 100 but are not result equivalent in general
Characterizing Schedules Based
on Serializability (cont’d.)
Conflict equivalence
Relative order of any two conflicting operations is
the same in both schedules
Serializable schedules
Schedule S is serializable if it is conflict equivalent
to some serial schedule S′.
Testing for serializability of a schedule
Figure 20.7 Constructing the precedence graphs for schedules A to D from Figure 20.5 to
test for conflict serializability (a) Precedence graph for serial schedule A (b) Precedence
graph for serial schedule B (c) Precedence graph for schedule C (not serializable) (d)
Precedence graph for schedule D (serializable, equivalent to schedule A)
How Serializability is Used for
Concurrency Control
Being serializable is different from being serial
Serializable schedule gives benefit of concurrent
execution
Without giving up any correctness
Difficult to test for serializability in practice
Factors such as system load, time of transaction
submission, and process priority affect ordering of
operations
DBMS enforces protocols
Set of rules to ensure serializability
-------------- END ------------
-------
LECTURE-4
CHAPTER 21
unlock(X)
Figure 21.5 Illustrating the deadlock problem. (a) A partial schedule of T1′ and T2′ that is
in a state of deadlock. (b) A wait-for graph for the partial schedule in (a).
Dealing with Deadlock and
Starvation (cont’d.)
Deadlock prevention protocols
1. Every transaction locks all the items it
needs in advance
2. Ordering all items in the database
ordering all the items in the database and making
sure that a transaction that needs several items will
lock them according to that order
Both approaches impractical
Transaction timestamp TS(T′), which is a unique
identifier assigned to each transaction.
Protocols based on a timestamp
Wait-die
Wound-wait
Dealing with Deadlock and
Starvation (cont’d.)
Transaction timestamp TS(T′), which is a unique
identifier assigned to each transaction.
The timestamps are typically based on the order
in which transactions are started; hence, if
transaction T1 starts before transaction T2, then
TS(T1) < TS(T2).
Notice that the older transaction (which starts
first) has the smaller timestamp value.
Two schemes that prevent deadlock based on a
timestamp
Wait-die
Wound-wait
Dealing with Deadlock and
Starvation (cont’d.)
Wait-die
If TS(Ti) < TS(Tj), then (Ti older than Tj) Ti is
allowed to wait; otherwise (Ti younger than Tj)
abort Ti (Ti dies) and restart it later with the
same timestamp.
Wound-wait (Opposite)
If TS(Ti) < TS(Tj), then (Ti older than Tj) abort
Tj (Ti wounds Tj) and restart it later with the
same timestamp; otherwise (Ti younger than
Tj) Ti is allowed to wait.
Dealing with Deadlock and
Starvation (cont’d.)
No waiting algorithm (NW)
If transaction unable to obtain a lock, immediately
aborted and restarted later
Cautious waiting algorithm (CW)
Deadlock-free
Dealing with Deadlock and
Starvation (cont’d.)
Deadlock detection
System checks to see if a state of deadlock exists
Wait-for graph
Victim selection
Deciding which transaction to abort in case of deadlock
Timeouts
If system waits longer than a predefined time, it aborts the
transaction
Starvation
Occurs if a transaction cannot proceed for an indefinite period of
time while other transactions continue normally
Solution: first-come-first-served queue
21.2 Concurrency Control Based
on Timestamp Ordering
A different approach to concurrency control involves using
transaction timestamps to order transaction execution for
an equivalent serial schedule.
Timestamp
Unique identifier assigned by the DBMS to identify a
transaction
timestamp values are assigned in the order in which
the transactions are submitted to the system,
Transaction start time
Concurrency control techniques based on
timestamps do not use locks
Deadlocks cannot occur
Concurrency Control Based on
Timestamp Ordering (cont’d.)
Generating timestamps
Counter incremented each time its value is
assigned to a transaction
Current date/time value of the system clock
Ensure no two timestamps are generated during the
same tick of the clock
General approach
Enforce equivalent serial order on the transactions
based on their timestamps
Concurrency Control Based
on Timestamp Ordering
(cont’d.)
Timestamp ordering (TO)
Allows interleaving of transaction operations
Must ensure timestamp order is followed for each
pair of conflicting operations
Each database item assigned two timestamp
values
read_TS(X)
write_TS(X)
CHAPTER 22