TRANSACTIONS 1

TRANSACTIONS

Transactions: Collection of operations that form a single logical unit of work is

called transaction.

A database system must ensure proper execution of transactions despite failures

either the entire transaction executes, or none of it does.

The transaction consists of all operations executed between the begin transaction
and end transaction.

To ensure integrity of the data, we require that the database system maintain the
following properties of the transactions.

 Atomicity: Either all operations of the transaction are related properly in the
database, or none are.

 Consistency: Execution of a transaction in isolation (that is, with no other

transaction executing concurrently) preserves the consistency of the database.

 Durability: After a transaction completes successfully, the changes it has made to

the database persist, even if there are system failures.

 Isolation: Even though multiple transactions may execute concurrently, the

system guarantees that, for every pair of transactions T i and Tj, it appears to Ti
that either Tj finished execution before Ti started, or Tj started execution after Ti
finished. Thus each transaction is unaware of other transactions executing
concurrently in the system.

These properties are often called the ACID properties.

Transactions are required to have the ACID properties:

o Atomicity ensures that either all the effects of a transaction are reflected in the
database, or none are; a failure cannot leave the database in a state where a
transaction is partially executed.
o Consistency ensures that, if the database is initially consistent, the execution of
the transaction (by itself) leaves the database in a consistent state.
o Isolation ensures that concurrently executing transactions are isolated from one
another, so that each has the impression that no other transaction is executing
concurrently with it.
o Durability ensures that, once a transaction has been committed, that
transaction’s updates do not get lost, even if there is a system failure.

RANJAN JANA, RCC Institute of Information Technology

TRANSACTIONS 2

Transaction state: A transaction must be in one of the following states:

o Active, the initial state, the transaction stays in this state while it is executing.
o Partially committed, after the final statement has been executed.
o Failed, after the discovery that normal execution can no longer proceed.
o Aborted, after the transaction has been rolled back and the database has been
restored to its state prior to the start of the transaction.
o Committed, after successful completion.

Partially Committe
Committed d

Active

Failed Aborted

Implementation of Atomicity and durability

Shadow copy scheme: Shadow copy scheme is based on making copies of the
database called shadow copies, assumes that only one transaction is active at a time.
The scheme also assumes that the database is simply a file on disk. A pointer called
db-pointer is maintained on disk; it points to the current copy of the database.

In shadow-copy scheme, a transaction that wants to update the database first

creates a complete copy of the database. All updates are done on the new database
copy, leaving the original copy. If at any point the transaction has to be aborted, the
system simply deletes the new copy. The old copy of the database has not been
affected.

RANJAN JANA, RCC Institute of Information Technology

TRANSACTIONS 3

Concurrent executions: Transaction-processing systems usually allow multiple

transactions to run concurrently.

Two good reasons for allowing concurrency

o Improved through put resource utilization.
o Reduced waiting time.

Schedules: The execution sequences of instructions of transactions are called

schedules. They represent the sequential order in which instructions are executed in
the system.

Serial schedule: Serial schedule consists of a sequence of instructions from various

transactions, where the instructions belonging to one single transaction appear
together in that schedule. For a set of n transactions, there exist n! different serial
schedules.

Serializable Schedule: A schedule S of n transactions is serializable if it is equivalent

to some serial schedule of the same n transactions.

T1 T1 T2
T2 Read(A)
Read(A) Temp:=A* 0.1
A:=A-50 A:=A-temp
Write (A) Write(A)
Read(B) Read(B)
B:=B+50 B:=B+ temp
Write(B) Write(B)
Read(A) Read(A)
Temp:=A* 0.1 A:=A-50
A:=A-temp Write (A)
Write(A) Read(B)
Read(B) B:=B+50
B:=B+ temp Write(B)
Write(B)
Schedule1: A serial schedule in which T1 Schedule2: A serial schedule in which T2
is followed by T2. is followed by T1.

RANJAN JANA, RCC Institute of Information Technology

TRANSACTIONS 4

Conflict Serializability : Let us consider a schedule S in which there are two

consecutive instructions Ii and Ij of transactions Ti and Tj , respectively (i ≠ j). If Ii
and Ij refer to different data items, then we can swap I i and Ij without affecting the
result of any instruction in the schedule. If I i and Ij refer to the same data item Q,
then the order of the two steps may matter. Since we are dealing with only read and
write instructions, there are four cases that we need to considered:
1) Ii= read (Q), Ij = read (Q). The order of Ii and Ij does not matter.
2) Ii= read (Q), Ij= write (Q). If Ii comes before Ij, then Ti does not read the value
of Q that is written by T j in instruction Ij. If Ij comes before Ii, then Ti reads
the value of Q that is written by Tj. Thus, the order of Ii and Ij matters.
3) Ii= write (Q), Ij= read (Q). The order of Ii and Ij matters for previous reasons.
4) Ii = write (Q), Ij= write (Q). Since both instructions are write operations, the
order of these instructions does not affect either Ti or Tj.
However, the value obtained by the next read (Q) instruction of S is affected, since
the result of only the latter o f two write instructions is preserved in the database.
Conflict: Ii and Ij are conflict if they are operations by different transactions on the
same data item, and at least one of these instructions is a write operation.
Conflict Equivalent: if a schedule S can be transformed into a schedule S' by a series
of swap of non-conflicting instructions, we say that S and S' are conflict equivalent.
Conflict Serializable: A schedule S is conflict serializable if it is conflict equivalent to
a serial schedule.

T1 T2
Read(A)
A:=A-50
Write (A)
Read(A)
Temp:=A* 0.1
A:=A-temp
Write(A)
Read(B)
B:=B+50
Write(B)
Read(B)
B:=B+ temp
Write(B)

Schedule3: A conflict serializable

Thus, schedule3 is conflict serializable since it is conflict equivalent to the serial

schedule1.

RANJAN JANA, RCC Institute of Information Technology

TRANSACTIONS 5

T3 T4
Read(Q)

Write(Q)

Write(Q)

Schedule 4

Schedule4 consist of only the significant operations (that is, the read and write) of
transactions T3 and T4. This schedule is not conflict serializable, since it is not
equivalent to either the serial schedule < T3, T4> or the serial schedule < T4, T3>. It
is possible to have two schedules that produce the same outcome, but that are not
conflict equivalent.

Recoverability: If a transaction Ti fails, for whatever reason, we need to undo the

effect of this transaction to ensure the atomicity property of the transaction.

Recoverable schedule: A recoverable schedule is one where, for each pair of

transactions Ti and Tj such that Tj reads a data item previously written by T i, the
commit operation of Ti appears before the commit operation of Tj.

T8 T9
Read(A)
Write(A)
Read(A)
Read(B)

Schedule 7

Schedule 7, with the commit happening immediately after the read (A) instruction,
is an example of a non-recoverable schedule, which should not be allowed.

Cascadeless schedules: A cascadeless schedule is one where, for each pair of

transactions Ti and Tj such that Tj reads a data item previously written by T i, the
commit operation of Ti appears before the read operation of Tj.

In which a single transaction failure leads to a series of transaction rollbacks, is

called cascading rollback.

RANJAN JANA, RCC Institute of Information Technology

TRANSACTIONS 6

Algorithm for determining conflict serializability: Consider a schedule S.

Step1: Construct a directed graph, called a precedence graph, from S. This graph
consists of a pair G= (V, E), where V is a set of vertices and E is a set of edges.
Step2: The set of vertices consists of all the transactions participating in the
schedule.
Step3: the set of edges consists of all edges T i → Tj for which one of three conditions
holds:
1) Ti executes write (Q) before Tj executes read (Q).
2) Ti executes read (Q) before Tj executes write (Q).
3) Ti executes write (Q) before Tj executes write (Q).
Step4: If the precedence graph for S has a cycle, then schedule S is not conflict
serializable. If the graph contains no cycles, then the schedule S is conflict
serializable.

T1 T2 T1 T2
Read(A)
Read(A) Write(A)
Write(A) Read(B)
T T T T
Read(B) Write(B)
Write(B) Read(A) 1 2
Read(A) 2 1

Write(A) Write(A)
Read(B) Read(B)
Write(B) Write(B)
T1 T2
Read(A)
Read(A)
Write(A)
Read(B) T T
Write(A)
1 2
Read(B)
Write(B)
Write(B)

A serializability order of the transactions can be obtained through topological

sorting, which determines a linear order consistent with the partial order of the
precedence graph.

Ti

RANJAN JANA, RCC Institute of Information Technology

TRANSACTIONS 7

Tj Tk

Tm

Ti Ti

Tj Tk

Tk Tj

Tm Tm

Illustration of topological sorting

RANJAN JANA, RCC Institute of Information Technology