UNIT IV TRANSACTION MANAGEMENT

TRANSACTION CONCEPTS AND CONCURRENCY CONTROL IN DBMS

Transaction concepts –properties –Schedules –Serializability –Concurrency Control –Two-
phase locking techniques.
4.1 Transaction concepts

What is Transaction?
A set of logically related operations is known as transaction. The main operations of a
transaction are:

Read(A): Read operations Read(A) or R(A) reads the value of A from the database and stores it
in a buffer in main memory.

Write (A): Write operation Write(A) or W(A) writes the value back to the database from buffer.

(Note: It doesn’t always need to write it to database back it just writes the changes to buffer this
is the reason where dirty read comes into picture)

Let us take a debit transaction from an account which consists of following operations:

R(A);

A=A-1000;

W(A);

Assume A’s value before starting of transaction is 5000.

The first operation reads the value of A from database and stores it in a buffer.

Second operation will decrease its value by 1000. So, buffer will contain 4000.

Third operation will write the value from buffer to database. So, A’s final value will be 4000.

But it may also be possible that transaction may fail after executing some of its operations. The
failure can be because of hardware, software or power etc. For example, if debit transaction
discussed above fails after executing operation 2, the value of A will remain 5000 in the database
which is not acceptable by the bank. To avoid this, Database has two important operations:

Commit: After all instructions of a transaction are successfully executed, the changes made by
transaction are made permanent in the database.

Rollback: If a transaction is not able to execute all operations successfully, all the changes made
by transaction are undone.

1
Properties of a transaction

Atomicity:

As a transaction is set of logically related operations, either all of them should be executed or
none. A debit transaction discussed above should either execute all three operations or none. If
debit transaction fails after executing operation 1 and 2 then its new value 4000 will not be
updated in the database which leads to inconsistency.

Consistency:

If operations of debit and credit transactions on same account are executed concurrently, it may
leave database in an inconsistent state.

For Example, T1 (debit of Rs. 1000 from A) and T2 (credit of 500 to A) executing
concurrently, the database reaches inconsistent state.

Let us assume Account balance of A is Rs. 5000. T1 reads A (5000) and stores the value in its
local buffer space. Then T2 reads A (5000) and also stores the value in its local buffer space.

T1 performs A=A-1000 (5000-1000=4000) and 4000 is stored in T1 buffer space. Then T2

performs A=A+500 (5000+500=5500) and 5500 is stored in T2 buffer space. T1 writes the value
from its buffer back to database.

A’s value is updated to 4000 in database and then T2 writes the value from its buffer back to
database. A’s value is updated to 5500 which shows that the effect of debit transaction is lost and
database has become inconsistent.

To maintain consistency of database, we need concurrency control protocols which will be

discussed in next article. The operations of T1 and T2 with their buffers and database have been
shown in Table 1.

T1 T1’s buffer space T2 T2’s buffer space Database

A=5000
R(A); A=5000 A=5000
A=5000 R(A); A=5000
A=A-1000; A=4000 A=5000 A=5000
A=4000 A=A+500 A=5500
W(A); A=5500 A=4000
W(A); A=5500

TABLE 1

2
Isolation:

Result of a transaction should not be visible to others before transaction is committed. For
example, let us assume that A’s balance is Rs. 5000 and T1 debits Rs. 1000 from A. A’s new
balance will be 4000. If T2 credits Rs. 500 to A’s new balance, a will become 4500 and after this
T1 fails. Then we have to rollback T2 as well because it is using value produced by T1. So a
transaction results are not made visible to other transactions before it commits.

Durable:

Once database has committed a transaction, the changes made by the transaction should be
permanent. e.g.; If a person has credited $500000 to his account, bank can’t say that the update
has been lost. To avoid this problem, multiple copies of database are stored at different locations.

What is a Schedule in transaction?

A schedule is a series of operations from one or more transactions.

A schedule can be of two types:

Serial Schedule: When one transaction completely executes before starting another
transaction, the schedule is called serial schedule. A serial schedule is always consistent. e.g.; If a
schedule S has debit transaction T1 and credit transaction T2, possible serial schedules are T1
followed by T2 (T1->T2) or T2 followed by T1 ((T2->T1). A serial schedule has low throughput
and less resource utilization.

Concurrent Schedule: When operations of a transaction are interleaved with operations of

other transactions of a schedule, the schedule is called Concurrent schedule. e.g.; Schedule of
debit and credit transaction shown in Table 1 is concurrent in nature. But concurrency can lead to
inconsistency in the database. The above example of a concurrent schedule is also inconsistent.

Question: Consider the following transaction involving two bank accounts x and y:

read(x);

x := x – 50;

write(x);

read(y);

y := y + 50;

write(y);

The constraint that the sum of the accounts x and y should remain constant is that of?

3
 • Atomicity
• Consistency
• Isolation
• Durability

Solution: As discussed in properties of transactions, consistency properties says that sum of

accounts x and y should remain constant before starting and after completion of transaction. So,
the correct answer is B.

4.2 ACID Properties in DBMS

A transaction is a single logical unit of work which accesses and possibly modifies the contents
of a database. Transactions access data using read and write operations.

In order to maintain consistency in a database, before and after the transaction, certain properties
are followed. These are called ACID properties.

Atomicity

By this, we mean that either the entire transaction takes place at once or doesn’t happen at all.
There is no midway i.e. transactions do not occur partially. Each transaction is considered as one
unit and either runs to completion or is not executed at all. It involves the following two
operations.

—Abort: If a transaction aborts, changes made to database are not visible.

—Commit: If a transaction commits, changes made are visible.

4
Atomicity is also known as the ‘All or nothing rule’.

Consider the following transaction T consisting of T1 and T2: Transfer of 100 from account X to
account Y.

If the transaction fails after completion of T1 but before completion of T2. (say, after write(X)
but before write(Y)), then amount has been deducted from X but not added to Y. This results in
an inconsistent database state. Therefore, the transaction must be executed in entirety in order to
ensure correctness of database state.

Consistency

This means that integrity constraints must be maintained so that the database is consistent before
and after the transaction. It refers to the correctness of a database. Referring to the example
above,

The total amount before and after the transaction must be maintained.

Total before T occurs = 500 + 200 = 700.

Total after T occurs = 400 + 300 = 700.

Therefore, database is consistent. Inconsistency occurs in case T1 completes but T2 fails. As a

result, T is incomplete.

Isolation

This property ensures that multiple transactions can occur concurrently without leading to the
inconsistency of database state. Transactions occur independently without interference. Changes
occurring in a particular transaction will not be visible to any other transaction until that
particular change in that transaction is written to memory or has been committed. This property
ensures that the execution of transactions concurrently will result in a state that is equivalent to a
state achieved these were executed serially in some order.

Let X= 500, Y = 500.

Consider two transactions T and T”.

5
Suppose T has been executed till Read (Y) and then T’’ starts. As a result, interleaving of
operations takes place due to which T’’ reads correct value of X but incorrect value of Y and
sum computed by

T’’: (X+Y = 50, 000+500=50, 500)

is thus not consistent with the sum at end of transaction:

T: (X+Y = 50, 000 + 450 = 50, 450).

This results in database inconsistency, due to a loss of 50 units. Hence, transactions must take
place in isolation and changes should be visible only after they have been made to the main
memory.

Durability:

This property ensures that once the transaction has completed execution, the updates and
modifications to the database are stored in and written to disk and they persist even if a system
failure occurs. These updates now become permanent and are stored in non-volatile memory.
The effects of the transaction, thus, are never lost.

The ACID properties, in totality, provide a mechanism to ensure correctness and consistency of
a database in a way such that each transaction is a group of operations that acts a single unit,
produces consistent results, acts in isolation from other operations and updates that it makes are
durably stored.

4.3 Schedules

Schedule, is a process of lining the transactions and executing them one by one.

When there are multiple transactions that are running in a concurrent manner and the order of
operation is needed to be set so that the operations do not overlap each other, Scheduling is
brought into play and the transactions are timed accordingly.

The basics of Transactions and Schedules is discussed in Concurrency Control (Introduction),

and Transaction Isolation Levels in DBMS articles. Here we will discuss various types of
schedules.

6
Serial Schedules:

Schedules in which the transactions are executed non-interleaved, i.e., a serial schedule is one in
which no transaction starts until a running transaction has ended are called serial schedules.

Example: Consider the following schedule involving two transactions T1 and T2.

T1 T2
R(A)
W(A)
R(B)
W(B)
R(A)
W(B)

where R(A) denotes that a read operation is performed on some data item ‘A’.This is a serial
schedule since the transactions perform serially in the order T1 —> T2

Non-Serial Schedule:

This is a type of Scheduling where the operations of multiple transactions are interleaved. This
might lead to a rise in the concurrency problem. The transactions are executed in a non-serial
manner, keeping the end result correct and same as the serial schedule. Unlike the serial schedule
where one transaction must wait for another to complete all its operation, in the non-serial

7
schedule, the other transaction proceeds without waiting for the previous transaction to complete.
This sort of schedule does not provide any benefit of the concurrent transaction. It can be of two
types namely, Serializable and Non-Serializable Schedule.

The Non-Serial Schedule can be divided further into Serializable and Non-Serializable.

4.4 Serializable:

This is used to maintain the consistency of the database. It is mainly used in the Non-Serial
scheduling to verify whether the scheduling will lead to any inconsistency or not. On the other
hand, a serial schedule does not need the serializability because it follows a transaction only
when the previous transaction is complete. The non-serial schedule is said to be in a serializable
schedule only when it is equivalent to the serial schedules, for an n number of transactions. Since
concurrency is allowed in this case thus, multiple transactions can execute concurrently. A
serializable schedule helps in improving both resource utilization and CPU throughput. These are
of two types:

1. Conflict Serializable:

A schedule is called conflict serializable if it can be transformed into a serial schedule by

swapping non-conflicting operations. Two operations are said to be conflicting if all conditions
satisfy:

 They belong to different transactions

 They operate on the same data item
 At Least one of them is a write operation

2. View Serializable:

A Schedule is called view serializable if it is view equal to a serial schedule (no overlapping
transactions). A conflict schedule is a view serializable but if the serializability contains blind
writes, then the view serializable does not conflict serializable.

Non-Serializable:

The non-serializable schedule is divided into two types, Recoverable and Non-recoverable
Schedule.

Recoverable Schedule:

Schedules in which transactions commit only after all transactions whose changes they read
commit are called recoverable schedules. In other words, if some transaction Tj is reading value
updated or written by some other transaction Ti, then the commit of Tj must occur after the
commit of Ti.

Example – Consider the following schedule involving two transactions T1 and T2.

8
 T1 T2
R(A)
W(A)
W(A)
R(A)
Commit
Commit

This is a recoverable schedule since T1 commits before T2, that makes the value read by T2
correct.

There can be three types of recoverable schedule:

Cascading Schedule:

Also called Avoids cascading aborts/rollbacks (ACA). When there is a failure in one
transaction and this leads to the rolling back or aborting other dependent transactions, then such
scheduling is referred to as Cascading rollback or cascading abort. Example:

Cascadeless Schedule:

Schedules in which transactions read values only after all transactions whose changes they are
going to read commit are called cascade less schedules. Avoids that a single transaction abort
leads to a series of transaction rollbacks. A strategy to prevent cascading aborts is to disallow a
transaction from reading uncommitted changes from another transaction in the same schedule.

In other words, if some transaction Tj wants to read value updated or written by some other
transaction Ti, then the commit of Tj must read it after the commit of Ti.

9
Example: Consider the following schedule involving two transactions T1 and T2.

T1 T2
R(A)
W(A)
W(A)
Commit
R(A)
Commit

This schedule is cascadeless. Since the updated value of A is read by T2 only after the updating
transaction i.e. T1 commits.

Example: Consider the following schedule involving two transactions T1 and T2.

T1 T2
R(A)
W(A)
R(A)
W(A)
abort
abort

It is a recoverable schedule but it does not avoid cascading aborts. It can be seen that if T1
aborts, T2 will have to be aborted too in order to maintain the correctness of the schedule as T2
has already read the uncommitted value written by T1.

Strict Schedule:

A schedule is strict if for any two transactions Ti, Tj, if a write operation of Ti precedes a
conflicting operation of Tj (either read or write), then the commit or abort event of Ti also
precedes that conflicting operation of Tj.

In other words, Tj can read or write updated or written value of Ti only after Ti commits/aborts.

Example: Consider the following schedule involving two transactions T1 and T2.

10
T1 T2
R(A)

R(A)
W(A)

commit

W(A)
R(A)
commit
This is a strict schedule since T2 reads and writes A which is written by T1 only after the
commit of T1.

Non-Recoverable Schedule:

Example: Consider the following schedule involving two transactions T1 and T2.

T1 T2
R(A)
W(A)
W(A)
R(A)
Commit
Abort

T2 read the value of A written by T1, and committed. T1 later aborted, therefore the
value read by T2 is wrong, but since T2 committed, this schedule is non-recoverable.

Note – It can be seen that:

Cascadeless schedules are stricter than recoverable schedules or are a subset of recoverable
schedules.

Strict schedules are stricter than cascadeless schedules or are a subset of cascadeless
schedules.

Serial schedules satisfy constraints of all recoverable, cascadeless and strict schedules and
hence is a subset of strict schedules.

11
The relation between various types of schedules can be depicted as:

Example: Consider the following schedule:

S: R1(A), W2(A), Commit2, W1(A), W3(A), Commit3, Commit1

Which of the following is true?

(A) The schedule is view serializable schedule and strict recoverable schedule

(B) The schedule is non-serializable schedule and strict recoverable schedule

(C) The schedule is non-serializable schedule and is not strict recoverable schedule.

(D) The Schedule is serializable schedule and is not strict recoverable schedule

Solution: The schedule can be re-written as: -

T1 T2 T3
R(A)
W(A)
Commit
W(A)
W(A)
Commit
Commit

12
First of all, it is a view serializable schedule as it has view equal serial schedule T1 —> T2 —>
T3 which satisfies the initial and updated reads and final write on variable A which is required
for view serializability. Now we can see there is write – write pair done by transactions T1
followed by T3 which is violating the above-mentioned condition of strict schedules as T3 is
supposed to do write operation only after T1 commits which is violated in the given schedule.
Hence the given schedule is serializable but not strict recoverable.

So, option (D) is correct.

4.6 Two-Phase Locking Techniques.

Two-phase locking (2PL)

The two-phase locking protocol divides the execution phase of the transaction into three parts.

In the first part, when the execution of the transaction starts, it seeks permission for the lock it
requires.

In the second part, the transaction acquires all the locks. The third phase is started as soon as
the transaction releases its first lock.

In the third phase, the transaction cannot demand any new locks. It only releases the acquired
locks.

There are two phases of 2PL:

Growing phase:

In the growing phase, a new lock on the data item may be acquired by the transaction, but none
can be released.

Shrinking phase:

In the shrinking phase, existing lock held by the transaction may be released, but no new locks
can be acquired.

13
In the below example, if lock conversion is allowed then the following phase can happen:

1. Upgrading of lock (from S(a) to X (a)) is allowed in growing phase.

2. Downgrading of lock (from X(a) to S(a)) must be done in shrinking phase.

Example:

The following way shows how unlocking and locking work with 2-PL.

Transaction T1:

Growing phase: from step 1-3

Shrinking phase: from step 5-7

Lock point: at 3

Transaction T2:

Growing phase: from step 2-6

Shrinking phase: from step 8-9

Lock point: at 6

Lock Point:

The Point at which the growing phase ends, i.e., when a transaction takes the final lock it needs
to carry on its work.

14