TRANSACTION MANAGEMENT

Transaction refers to a collection of operations that form a single logical unit of work.
e.g.- Transfer of money from one account to another is a transaction which consists of two
updates, one to each account.
1. read A
2. A : = A – 50
3: write (A)
4. read (B)
5. B : = B + 50
6. write (B)

ACID properties:
A Atomicity, C Consistency, I Isolation, D Durability
Atomicity:
Either all operations of the transaction are properly reflected in the database or none.

Consistency:
It involves beginning a transaction with a consistent database and finishing with a consistent
database.
In between, database may be temporarily inconsistent.
When the transaction completes successfully, the database must be in consistent set.

Isolation:
Although multiple transaction may execute concurrently each transaction must be unaware of
other concurrently executing transactions. Intermediate transaction results must be hidden
from other concurrently executed transactions.

Durability:
After a transaction completes successfully, the changes it has made to the database persists
even if there is a system failure.
 Termination

Active:
The initial state when the transaction has started execution.

Partially Committed:
At any given point of time, if the transaction is executing property, then it is going towards its
COMMIT point.

Committed:
The values generated during the execution are all stored in a volatile storage. If the transaction
fails for some reason, the temporary values are no longer required and the transaction is set
the roll back.
It means that any change made to the database by this transaction up to the point of the failure
must be undone.
After the transaction has been rolled back, the database restores its state prior to the
transaction.
COMMIT:
If no failure occurs, then the transaction reaches the COMMIT point. All the temporary values
are written to the stable storage and transaction has said to be committed.

Terminated:
Either committed or aborted, the Transaction finally reaches the terminated state.
Handling of Atomicity, Durability:
Shadow Database Scheme:

Before Update

During Update

After Update

All updates are made on a shadow copy of database.

DB-pointer always points to the current consistent copy of the database.
A transaction performing read or write operations using I/o devices may not be using the CPU
at a particular point of time.
Thus while one transaction is performing I/O operation, the CPU can process another
transaction.
This is possible because the CPU and I/O system in the computer system are capable of
operating in parallel. This overlapping of I/O and CPU activities reduces the amount of time for
which the disks and processors are idle and thus increases the throughput of the system.
To reduce average response time:
The interleaved expression of a short and long transaction to be completed quickly, if a short
transaction is executed after the execution of a long transaction in a serial order. The short
transaction may have to wait for a long time leading to unpredictable delays in executing a
transaction.
On the other hand, if these transactions are executed concurrently, which reduces the
unpredictable delays and thereby reduces the average response time.
Concurrent execution of multiple transaction is done to
1) Increase system throughput.
2) To reduce average response time.
A schedule is a collection of many transactions which is implemented as a unit depending upon
how these transactions are arranged within a schedule.

A schedule can be of two types:

1) Serial: transactions are executed one after another.
2) Concurrent: The transactions are executed in a time shared method.

Serial:
T1
Read A,
A = A – 100;
Write A
Read B
B = B + 100;
Write B
 T2
Read A
Temp = A*0.1
Read C
C = C + Temp;
Write C;
In concurrent schedule CPU time is shared among two or more transactions in order to run
them concurrently. However, this creates a possibility that more than one transaction may
need to access a single data item for read or write purpose and the database could contain
inconsistent values if such accesses are not handled properly.

Concurrent:

T1 T2
Read A,
A = A – 100;
Write A
Read A
Temp = A*0.1
Read C
C = C + Temp;
Write C;
Read B
B = B + 100;
Write B;
Serializability:
When several concurrent transactions are trying to access the same data item the instructions
within this concurrent transactions, must be ordered in some ways so as there are no problem
in accessing or releasing shared data-item.

There are two aspects of serializability:

1) Conflict Serializability;
2) View Serializability.

Conflict Serializability:
Two instructions of two different transactions may want to access the same data item in order
to perform a read or write operation.
Conflict Serializability deals with detecting whether the instructions are conflicting in any way
and specifying the orders in which these two instructions will be executed in case there is any
conflict.
A conflict arises if at least one or both of the instructions is a right operation.

The following rules are important in conflict serializability:

i) If two instructions of the two concurrent transactions are both read operation, then
they are not in conflict and can be allowed to take place in any order.
ii) If one of the instructions wants to perform a read / write operation and the other
instruction want to perform a write / read operation and they are in conflict hence
their ordering is important.
iii) If both the transactions are for write operation, then they are in conflict.
T1 T2 T1 T2 T1 T2

Read(A) Read(A) Read(A)

Write(A) Write(A) Write(A)
Read(A) Read(A) Read(B)
Write(A) Read(B) Read(A)
Read(B) Write(A) Write(A)
Write(B) Write(B) Write(B)
Read(B) Read(B) Read(B)
Write(B) Write(B) Write(B)
 T1 T2 T1 T2

Read(A) Read(A)
Write(A) Write(A)
Read(B) Read(B)
Read(A) Write(B)
Write(B) Read(A)
Write(A) Write(A)
Read(B) Read(B)
Write(B) Write(B)

** These are all conflict serializable and serial schedule.

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. We say that a schedule S is conflict
serializable if it is conflict equivalent to a serial schedule.

T3 T4

Read(Q)
Write(Q)
Write(Q)

**Swapping can’t be done as ordering is important here. So this is not conflict serializable.

View Serializability:
Let S and S’ be two schedules with the same set of transactions. S & S’ are view equivalent if the
following three conditions are made for each data item Q.
i) If in schedule S transaction Ti reads the initial value of Q, then in schedule S’ also
transaction Ti must read the initial value of Q.
ii) If in schedule S, transaction Ti read Q and that value was produced by a write(Q) and
that value is produced by a read(Q) executed by a transaction Tj, then in schedule S’
 also transaction Ti must read the value of Q, that was produced by the same write(Q)
operation transaction Tj.
iii) The transaction that performs the final write(Q) operation in schedule S, must also
perform the final write(Q) operation in schedule S’.
A schedule S is view Serializable, if it is view equivalent to a serial schedule.
View Equivalent
S S’
T3 T4 T6 T3 T4 T6

Read(Q)
Read(Q)
Write(Q)
Write(Q)
Write(Q)
Write(Q)
Write(Q)
Write(Q)

View Serializable but not conflict serializable blind-write

** Every conflict serializable schedule is also view serializable but there are also view
serializable schedule which are not conflict serializable.

1) Conflict equivalent
2) View equivalent
3) Result equivalent (but not conflict equivalent)
4) Recoverable Schedule
5) Cascadeless Schedule

** (4) and (5) are applicable for transaction failures during concurrent execution.
 T1 T5 T1 T5

Read(A)
A = A – 50 Read(A)

Write(A) A = A – 50

Read(B) Write(A)

B = B + 50 Read(B)

Write(B) B = B – 10

Read(B) Write(B)

B = B – 10 Read(B)

Write(B) B = B + 50

Read(A) Write(B)

A = A + 10 Read(A)

Write(A) A = A + 10
Write(A)

A Recoverable Schedule is one where for each pair of transaction Ti & Tj, Tj reads a data-
item previously written by Ti, the commit operation of Ti appears before the commit
operation of Tj.
T8 T9

Read(A)
Write(A)
Read(A)
Read(B)

Commit
Commit
1) T8 fails.
2) T9 commits immediately after Read(A). T9 has read the value of data item A, written by
T8.
We must abort T9 to ensure the atomicity of transaction. However, T9 is already
committed, can’t be aborted. So it is impossible to recover the situation.
 So commit operation of T8 should occur before the commit operation of T9.

Cascadeless Schedule:
To recover correctly from the failure of a transaction Ti in a schedule we may have to roll back
several transactions. Such situations occur if transactions has resd data written by Ti.
T10 T11 T12

Read(A)
Read(B)
Write(A)

Commit Read(A)
Write(A)

Commit Read(A)

Commit

Every Cascadeless schedule is recoverable.

Precedence Graph:
A precedence graph is a directed graph G = (N, E) where N = {T1, T2, . . ., Tn} is a set of nodes
and E = {e1, e2, . . ., en} is a set of directed edges. For each transaction Ti in a schedule,
there exists a node in the graph. The edge ei (connecting Ti Tj ) is created if one of the
operations in Ti appears in the schedule before some conflicting operations in Tj.
Algorithm to test conflict serializability of a Schedule S:
1) For each transaction Ti participating in the schedule S, create a node lebelled Ti.
2) If Tj executes a read /(write) operation after Ti executes a write/(read) operation on any
data item, create an edge (Ti Tj) in the precedence graph.
3) If Tj executes a write operation after Ti executes a write operation on any data item Q,
create an edge (Ti Tj) in the precedence graph.
4) If the resultant precedence graph is a cyclic, then the schedule S is conflict serializable.
Otherwise, it is not conflict serializable.
 T1 T2 T3

Read (P)
Read(R)
Read(P)
Read(R)
Read(Q)
Read(Q)
Write(P)
Write(R)
Write(Q)
Write(Q)

Concurrency Control:
Implementation:
When multiple transaction all trying to access the same shareable , there could arise many
problems and the access control is not done properly. There are some important mechanism by
which access control can be maintained.

Lock based Protocol:

Write operation: problem; Read problem ; No problem ;

Write Operation:
When a transaction writes some value into a data item the content of that data item remains in
an inconsistent state, starting from the moment when the writing operation begins up to the
moment the writing operation is over if we allow any other transaction to read or write the
value of data item during the write operation. Those transactions will read an inconsistent
value.
There are two types of locks:

1) Shared Lock:
A transaction may acquire shared lock in data item in order to read its content , the
lock is shared in the sense that any other transaction can acquire the shared lock on
that same data item for reading purpose.
T1 T2 T1 T2

Lock – X(A) Lock X(A)

Read (A) Read (A)

A = A – 100 …

Lock S(A)(not Unlock (A)

possible
Lock S(A)
because of Lock
X(A) by T1) …

Read (A) Unlock (C)

Temp= … Lock X(B)

Unlock(A) …

Lock X(C) Unlock(B)

Write (A) …….

Unlock (A) Unlock (C)

Lock – X(B)
Read (B)
…….
Unlock (B)

2) Exclusive Lock:
A transaction may acquire exclusive lock on a data item in order to both read and write
into it. The lock is exclusive in the sense that no other transaction can acquire any kind
of lock on that same data item. Exclusive lock is used for update operation.
 S X

S true False

X false False

Lock Compatibility matrix

Lock – X(A) B = B +100 Lock – X(C)
Read (A) Write (B) Read (C)
A = A – 100 Unlock (B) C = C + Temp
Write (A) Lock – S(A) Write (C)
Unlock (A) Read (A) Unlock (C)
Lock – X(A) Temp = A * 1
Read (A) Unlock (A)

Two phase locking protocol:

The two phase locking protocol define rules of how to acquire locks on data item and
how to unlock the locks assuming a transaction can only be in one of the two phases.
Growing phase:
In this phase the transaction can only acquire locks.
Ultimately the transaction reaches a point when all locks it may need has been acquired.
This point is called a lock point.
Shrinking phase:
After reaching lock point the transaction reaches this phase. No new lock can be
acquired in this phase.

Two different version of locking protocol:

i) Strict two phase locking protocol
ii) Rigorous two phase locking protocol.
In strict two phase locking protocol, a transaction cannot release any of its acquired
exclusive lock unless the transaction commits. In such a case T1 would not release the
exclusive lock on A, until it finally commits which makes it impossible to acquire the
shared lock on A at a time when transaction is not been committed.