Transaction and

Concurrency Control
UNIT-4

-Navjot Kaur
What we will cover?
• Transaction system concepts 
• Desirable properties of transactions 
• Schedules 
• Serializability of schedules  
• Concurrency control
• Recoverability 
 Transaction Processing Systems

• Transaction Processing Systems are the

systems with large databases and hundreds of
concurrent users executing database transactions.

• For example airline reservations, banking,

stock markets, etc.
Transaction
• A transaction is an action or series of actions that are being performed
by a single user or application program, which reads or updates the
contents of the database.

• A transaction can be defined as a logical unit of work on the database.

• This may be an entire program, a piece of a program, or a single
command (like the SQL commands such as INSERT or UPDATE),
and it may engage in any number of operations on the database.
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.
 Example
• A transfer of money from one bank account to
another requires two changes to the database
both must succeed or fail together.
- Subtracting the money from the savings account
balance.
- Adding the money to the checking account
balance.
Example
Processes of Transaction
• Read Operation: To read a database object, it
is first brought into main memory from disk
and then its value is copied into a program
variable.
A
Read (2) 5000

INPUT (1) 5000 A

Physical
5000 a Block (X)
Program
Variable
Main Memory Disk
(RAM)
Processes of Transaction
• Write Operation: To write a database object,
an in-memory copy of the object is first
modified and then written back to disk.

A
Write (1) 5000 to 7000

OUTPUT (2) 5000 to 7000 A

Physical
7000 a Block (X)
Program
Variable
Main Memory Disk
(RAM)
What is a transaction
What is a transaction
Transaction
A transaction is a unit of program execution that accesses and
possibly updates various data items.
• Collection of operations that form a single logical unit of work.
Transaction
Two main issues to deal with:
– Failures of various kinds, such as hardware failures and system
crashes
– Concurrent execution of multiple transactions
Transaction Properties: ACID
• Atomicity
• Consistency
• Isolation
• Durability
Transaction Properties: ACID
A transaction is a unit of program execution that accesses and possibly
updates various data items. To preserve the integrity of data the
database system must ensure:
1. Atomicity: Either all operations of the transaction are properly
reflected in the database or none are.
2. Consistency: Execution of a transaction in isolation preserves the
consistency of the database.
Transaction Properties: ACID
Example: inconsistency
Transaction Properties: ACID
Isolation: if several transactions are executed concurrently (or in
parallel), then each transaction must behave as if it was executed in
isolation. It means that concurrent execution does not result an
inconsistent state.

– That is, for every pair of transactions Ti and Tj , it appears to Ti that

either Tj , finished execution before Ti started, or Tj started execution
after Ti finished.
Transaction Properties: ACID
Durability: After a transaction completes successfully, the changes it
has made to the database persist, even if there are system failures.
Transaction Properties: Example
Transaction Properties: Example

Atomicity requirement
– if the transaction fails after step 3 and before step 6, money will be
“lost” leading to an inconsistent database state
– the system should ensure that updates of a partially executed
transaction are not reflected in the database

Durability requirement — once the user has been notified that the
transaction has completed (i.e., the transfer of the $50 has taken
place),
the updates to the database by the transaction must persist even if
there are software or hardware failures
Transaction Properties: Example
Consistency requirement:
– the sum of A and B is unchanged by the execution of the
transaction
In general, consistency requirements include
• primary keys and foreign keys
• Implicit integrity constraints
• A transaction must see a consistent database.
• During transaction execution the database may be temporarily
inconsistent.
• When the transaction completes successfully the database must be
consistent
– Erroneous transaction logic can lead to inconsistency
Transaction Properties: Example
Isolation requirement
— if between steps 3
and 6, another
transaction T2 is
allowed to access the
partially updated
database, it will see an
inconsistent database
(the sum A + B will be
less than it should be).
Transaction Properties: Example
Isolation can be ensured by running transactions serially
– that is, one after the other.

Result of transaction should not be visible to others before transaction is

committed.

Durable: Once database has committed a transaction, the changes made by the
transaction should be permanent.

e.g. if a person has credited $50000 to his account, bank cant say that the
update has been lost.

To avoid this problem, Multiple copies of database are stored at different

locations.
Question
• Which component of DBMS manages atomicity
a. Transaction management component
b. Concurrency control component
c. Recovery management component
 Transaction States
• Active state- the initial state; the transaction stays in this
state while it is executing .
• Partially committed state- after the final statement has
been executed.
• Failed state -- after the discovery that normal execution can
no longer proceed.
• Aborted state- 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 can be done only if no internal logical
error
- kill the transaction
• Committed state - after successful completion
State of Transition
Schedules
• Schedule – a sequence of instructions that specify the chronological
order in which instructions of concurrent transactions are executed
• a schedule for a set of transactions must consist of all instructions of those
transactions
• must preserve the order in which the instructions appear in each individual
transaction.
• A transaction that successfully completes its execution will have a
commit instructions as the last statement
• by default transaction assumed to execute commit instruction as its last step
• A transaction that fails to successfully complete its execution will
have an abort instruction as the last statement
Schedule
• It is a list of actions from a set transactions must consist of all
instructions of that transaction and must preserve the order in which
instructions appear in individual instruction.
Schedule Types
1. Complete Schedule
A schedule that contains either an abort or commit for each transaction
whose actions are listed in it is called a complete schedule.

2. Serial Schedule
Each schedule consists of a sequence of instructions from various
transactions where the instructions belonging to one single transaction
appear together in that schedule.
Schedule Types
2. Serial Schedule
If transactions are executed from start to finish, one by one then that
schedule is called Serial Schedule.
T1 T2
A=A+100
B=B-100
A=A*2.8
B=B*2.8
Schedule Types
3. Non-Serial Schedule
A schedule in which the operations from a set of concurrent transactions
are interleaved.
T1 T2
A=A+100
A=A*2.8

B=B-100
B=B*2.8
Schedule Types
4. Equivalent Schedule
Effect of execution of one schedule is identical to second.

5. Serializable Schedule
A non-serial schedule that is equivalent to some serial execution of
transactions is called serializable schedule
 Conflict of operations
• The order of read/write operations in a schedule can be changed depending
upon the data objects they related to, but sometimes orders cant be
changed.

• Those read/write operations whose order cant be changed without affecting

the consistency of the data are called Conflict Operations.
 Conflict of operations
• There are some rules to define conflict operations:

1. If two transactions only read, they do not conflict and the order is not
important
2. If two transactions read/write completely separate data objects, they
don’t conflict and order is not important
3. If one transaction writes a data object and another either reads or writes
the same data object, the order of execution is important.
 Conflict of operations
• There are some rules to define conflict operations:

1. If two transactions only read, they do not conflict and the order is not
important
2. If two transactions read/write completely separate data objects, they
don’t conflict and order is not important
3. If one transaction writes a data object and another either reads or writes
the same data object, the order of execution is important.
Conflicting Instructions
T1 T2
R(A)
W(A)
R(A)
R(B)
W(A)
W(B)
R(B)
W(B)

1. Swap R(B) of T1 with R(A) of T2

2. Swap W(B) of T1 with W(A) of T2
3. Swap W(B) of T1 with R(A) of T2
Conflicting Instructions
T1 T2
1. Swap R(B) of T1 with R(A) of T2 R(A)
2. Swap W(B) of T1 with W(A) of T2 W(A)
3. Swap W(B) of T1 with R(A) of T2 R(A)
R(B)
W(A)
W(B)
R(B)
W(B)
Conflict Equivalent

If a schedule S can be transformed into a schedule S1 by a series of swaps on non-

conflicting instructions then S and S1 are conflict equivalent

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

A schedule ‘S’ is conflict serializable if it is conflict equivalent to a serial schedule.

T1 T2 T1 T2
A=A+100 A=A+100
A=A*7.06 B=B-100
B=B-100 A=A*7.06
B=B*7.06 B=B*7.06
Examples: Schedule 1
• Let T1 transfer $50 from A to B, and T2 transfer 10% of the balance from A to B.
• A serial schedule in which T1 is followed by T2 :

A= 1000
B=2000
Schedule 2
• A serial schedule where T2 is followed by T1
Schedule 3

• Let T1 and T2 be the transactions defined previously. The following

schedule is not a serial schedule, but it is equivalent to Schedule 1.

In Schedules 1, 2 and 3, the sum A + B is preserved.

Schedule 3

• Let T1 and T2 be the transactions defined previously. The following

schedule is not a serial schedule, but it is equivalent to Schedule 1.

Schedule 3 Schedule 1
Schedule 4

• The following concurrent schedule does not preserve the value of

(A + B ).
Concurrency
• When more than one transactions are executing at a time
What are the advantages of having concurrency
Waiting Time
Response Time
Resource Utilization
Efficiency
Problems in Concurrency?
• various problems that can arise due to concurrency.
• Following are some of them:
• Dirty Read Problem
• Unrepeatable Read Problem
• Phantom Read Problem
• Lost update Problem
 Problems in Concurrency
• The Lost Update Problem
-This occurs when two transactions that access the same
database items have their operations interleaved in a way
that makes the value of some database item incorrect.

• The Temporary Update (or Dirty Read) Problem

- This occurs when one transaction updates a database item

and then the transaction fails for some reason.
- The updated item is accessed by another transaction
before it is changed back to its original value.
Problems in Concurrency
• The Incorrect Summary Problem
- If one transaction is calculating an aggregate summary
function on a number of records while other transactions
are updating some of these records, the aggregate
function may calculate some values before they are
updated and others after they are updated.
Concurrent execution is uncontrolled:
Suppose:
(a) The lost update problem.
X=2000
N=500
Y=1000
M=100
Uncommitted data or dirty read problem
T1 T2 VALUES
R(LOAN_BAL,b) Suppose b=10,000
B=b+2000 b=12000
W(LOAN_BAL, b) Loan balance set to 12000
R(LOAN_BAL, b) Read loan balance 12000 in b
b=b-3000 Changes b=9000
Rollback(T1)
W(LOAN_BAL, b) Loan balance set to 9000
• Uncommitted data or dirty read problem:
• In a dirty read problem, A is processing an order for a client for
150 items.
• He checks from the ITEMS table that there are 300 available
items.
• So he starts placing the order.
• A confirms the order for 150 items and updates the ITEMS table
and sets the quantity to 150. Now, B receives an order for 200
items.
• He checks the ITEMS table to find that there is not enough
inventories (150 available) and rejects the order.
• By using business rules and transactions a note is
sent informing that more items are required.
• Now, due to some reason client asks A to cancel
the order, so A cancels the order, rolls back and
updates the ITEMS table back to 300 items.
• This problem is known as dirty read because B
saw the uncommitted update of A.
Unrepeatable Read Problem Reading Again
the value of X

T1 T2
R(X)
R(X)
Performed some operation
W(X)
R(X)
Phantom Read Problem
Reading an
attribute which
does not exists

T1 T2
R(X)
R(X)
Delete X
R(X)
 Not read any
Lost Update Problem value. We call it
as blind write

T1 T2
R(A) Which value
this
W(A)
transaction is
W(A) writing?
Commit
Commit
Question
In a dirty read problem …….

A. one transaction reads an uncommitted value of another transaction

B. one transaction reads the committed value for another transaction
C. one transaction reads another transaction
D. one transaction commits another transaction.
Question
• In ………. one transaction overwrites the changes of another transaction.
A. Unrepeatable read problem
B. lost update problem
C. Phantom read problem
D. dirty read problem