Unit IV

Transaction Management
(Part 1)
Dr. D Jinil Persis
Associate Professor,
SCS-HITS
 Topics Covered
Transaction Processing – Introduction- Need
for Concurrency control- Desirable properties
of Transaction- Schedule and Recoverability-
Serializability and Schedules Shadow Paging.
 Transaction Processing
• Transaction:
– Collection of operations that form a single logical
unit of work
– A unit of program execution that accesses and
possibly updates various data items
– They are initiated by user program which has
Begin transaction
…..
End transaction
 ACID – Properties of transaction
• Either all operations in the transaction are reflected in
Atomicity the database or none

• Execute a transaction in isolation i.e, no concurrent

Consistency transaction executed leading to inconsistent data update

• Even if concurrent execution of transactions are allowed

Isolation the database must guarantee the every pair of concurrent
transaction (ti,tj) should maintain serializability

• After the transaction is completed that changes made

Durability must retain in DB even after a power failure
 Operations of transaction

Read(X) Write(X)

• Transfer data item • Transfer data item

X from DB to X from local
local buffer buffer belonging
belonging to the to the transaction
transaction that that executed
executed read write operation to
operation DB
 Example Transaction
Ti is the transaction that transfers 50 from
Account A to Account B
Ti: read(A);
A:=A-50;
write(A);
read(B);
B:=B+50;
write(B);
 Transaction state
Active
• the initial state; the transaction stays in this state while it is executing

Partially committed
• after the final statement has been executed

Failed
• after the discovery that normal execution can no longer proceed.

Aborted
• after the transaction has been rolled back and the database restored to its state prior
to the start of the transaction. Two options after it has been aborted:
• Restart the transaction
• It can be done only if no internal logical error
• Kill the transaction

Committed
• after successful completion
State diagram
 Shadow copy technique
• For implementing atomicity and durability
• Recovery management component of database
• Make shadow copy of the DB
 Need for concurrency
• Concurrent execution of multiple transactions are
allowed in DB
• Transaction has I/O activity and CPU activity.
When one transaction does I/O other can use CPU
– improves throughput
– improves resource utilization
• Transaction may be short or long. Concurrent
execution avoid the waits of short transactions for
long transactions
– reduces waiting time and response time
 Example of concurrency
• Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B.
• An example of a serial schedule in which T1 is followed by T2 :
This is also a serial schedule
This is not a serial schedule
A+B is not preserved
 Serializability
• Serializable schedule is the one in which each
transaction preserves database consistency.
• Two type are
– conflict serializability
– view serializability
 Conflict serializability
• Let li and lj be two Instructions of transactions Ti and Tj
respectively. Instructions li and lj conflict if and only if
there exists some item Q accessed by both li and lj, and
at least one of these instructions wrote Q.
li = read(Q), lj = read(Q). li and lj don’t conflict.
li = read(Q), lj = write(Q). They conflict.
li = write(Q), lj = read(Q). They conflict
li = write(Q), lj = write(Q). They conflict
• If a schedule S can be transformed into a schedule S’
by a series of swaps of non-conflicting instructions, we
say that S and S’ are conflict equivalent
 Conflict removal
Swapping
 View Equivalence
Both the schedule result the system in same final state

Two schedules S and S’ are view equivalent if three

conditions are met:
1. If in schedule S, transaction Ti reads the initial value of data
Same data is read
by both schedules

item Q, then in schedule S’ also transaction Ti must read the

initial value of Q.
2. If in schedule S transaction Ti executes read(Q), and that
value was produced by transaction Tj (if any), then in
schedule S’ also transaction Ti must read the value of Q that
was produced by the same write(Q) operation of transaction
Tj .
3. The transaction (if any) that performs the final write(Q)
operation in schedule S must also perform the final write(Q)
operation in schedule S’.
S and S’ are view equivalent
Schedule S Schedule S’
S and S’ are not view equivalent
Schedule S Schedule S’
 View Serializablility
Schedule S is view serializable if it is view
equivalent to a serial schedule

Every conflict serilizable schedule is view

serializable but every view serializable
schedule is not conflict serializable schedule
 Blind writes
 Consider the following view serializable schedule

 This is not conflict serializable. Every view

serializable schedule that is not conflict
serializable has blind writes.
 Recoverability
• When concurrent transactions (Ti,Tj) failed, the
effect of failure will lead to inconsistency
• ACID properties of the transaction are
disturbed
• Recoverability is the study of recovery
techniques from transaction failure
 Recoverable schedule
• For each pair of concurrent transactions
<Ti,Tj> in a schedule,
– if a transaction Tj reads a data item previously
written by a transaction Ti ,
– then the commit operation of Ti must appear
before the commit operation of Tj.
• Such a schedule is called as recoverable
schedule
 Recoverable Vs. Not recoverable

Schedule S

S is not recoverable because

If T8 should abort, T9 would have read
an inconsistent database state.
 Cascadeless schedules
Not cascadeless Definition:
For each pair of transactions Ti and Tj
such that Tj reads a data item
previously written by Ti,
the commit operation of Ti
appears before the read operation of Tj.

Every cascadeless schedule is also recoverable

It is desirable to restrict the schedules to those
that are cascadeless
 Cascading rollbacks
A single transaction failure leads to a series of transaction rollbacks.
Consider the following schedule where none of the transactions has yet
committed (so the schedule is recoverable)

If T10 fails, T11 and T12 must also be rolled back.

• leads to the undoing of a significant amount of work
 Concurrency control
• Concurrency control is the process of keeping the
DB in the consistent state no matter how efficient
time sharing and resource efficient the schedule is
• Trivially serializable
– The transaction which is using A obtains a lock on A
so that no transaction can access A till the transaction
that has obtained lock releases it by commit operation
– Such a schedule is also cascadeless
– This leads to poor degree of concurrency and poor
performance
 Goal of concurrency
• High degree of concurrency
• All schedules are conflict serializable
• All schedules are view serializable
• All schedules are cascadeless
 Precedence graph
Consider a schedule with transactions T1, T2, ..., Tn.
Precedence graph is a direct graph G(V,E) where
 V is the vertex set, the vertices are the transactions and
 E is the arc set
If Ti→Tj exists, if one of the three conditions holds:
 Ti executes write(Q) before Tj executes read(Q)
 Ti executes read(Q) before Tj executes write(Q)
 Ti executes write(Q) before Tj executes write(Q)
an arc from Ti to Tj is drawn if the two transaction conflict,
and Ti accessed the data item on which the conflict arose
earlier.
If Ti→Tj exists, then in any schedule, Ti must appear before Tj
Example graph
Example graph

T2 T1
Example graph

T1
T2
Test for serializability
Steps to test serializability

•Construct a precedence graph

•Execute Cycle detection algorithm
•If there is a cycle then the
schedule is said to be conflict
serializable

If precedence graph is acyclic, the serializability

order can be obtained by a topological sorting of the
graph.
That is, a linear order consistent with the partial
order of the graph.
For example, a serializability order for the
schedule (a) would be one of either (b) or (c)