Transactions Management

 ConcurrencyControl
 Database Recovery

1 Concurrency Control
 Transactions Management
 Transactions Management deals with the problem of
always keeping the database in a consistent state even
when concurrent accesses and failures occur
 The database can (and usually is) temporarily
inconsistent during the execution of a transaction. The
important point is that the database should be
consistent when the transaction terminates

2 Concurrency Control
 Transaction
 A transaction is a series of actions, carried out by a
single user or application program, which must be
treated as a logical unit of work.
 A transaction is a unit of consistent and reliable
computation.
 Example the transfer of funds from one account to
another: either the entire operations is carried out or
none of the operation is carried out.
 Transactions transform the database from consistent
state to another consistent state.

3 Concurrency Control
 Transactions in SQL
 Consider the following SQL statement
UPDATE Project
SET Budget=Budget*1.1
WHERE Pname=‘Engineering’
 This can be translated into a transaction as follows:
Begin_Transaction Budget_Update
Begin
EXEC SQL UPDATE Project
SET Budget=Budget*1.1
WHERE Pname=‘Engineering’
End

4 Concurrency Control
 Transaction in SQL

 (Implicit beginning of transaction)

– SELECT …;
– UPDATE …;
– ……
– ROLLBACK | COMMIT;
 ROLLBACK (transaction abort)
– Will undo the the partial effects of the transaction
– May be initiated by the DBMS

5 Concurrency Control
 Properties of a Transaction: ACID

 Atomicity
– Transactions are either done or not done
– They are never left partially executed
 Consistency
– Transactions should leave the database in a consistent state
 Isolation
– Transactions must behave as if they were executed in isolation
 Durability
– Effects of completed transactions are resilient against failures

6 Concurrency Control
 Concurrency Control
 Goal: ensure the “I” (Isolation) in ACID
T1 : T2 :
read(A); read(A);
write(A); write(A);
read(B); read(C);
write(B); write(C);
commit; commit;

A B C

7 Concurrency Control
 DBMS Components
 Transactions Manager - It is the responsibility of the
Transactions Manager of a DBMS to ensure transactions do not
interfere with one another and corrupt the database.
 Scheduler - Responsible for implementing a particular strategy for
concurrency control. Also called the Lock Manager (for those
systems that use locking as the means of managing concurrency)
 Recovery Manager- Ensures that the database is restored to the
state it was in before the start of the transaction.
 Buffer Manager - Responsible for the transfer of data between
disk storage and memory.

8 Concurrency Control
 Conflicting Operations
 Two operations on the same data item conflict if
at least one of the operations is a write
– r(X) and w(X) conflict
– w(X) and r(X) conflict
– w(X) and w(X) conflict
– r(X) and r(X) do not
– r/w(X) and r/w(Y) do not
 Order of conflicting operations matters
– If T1 .r(A) precedes T2 .w(A), then conceptually, T1 should
precede T2

9 Concurrency Control
 Interference Between
Concurrent Transactions

 There are many ways in which concurrently executing

transactions can interfere with one answer and so compromise
the integrity and consistency of the DB. Three examples of such
interference are:
 Lost Update Problem
 Uncommitted Dependency Problem
 Inconsistency Analysis Problem

10 Concurrency Control
 The Lost Update Problem

 An apparently successfully completed update operation by one

user can be overridden by another user.
 Consider this situation.

Time Transaction A Transaction B

t1 Read R -
t2 - Read R
t3 Write R -
t4 - Write R
 Transaction A’s update is lost at time t4 because transaction B
overwrites it without even looking at it!

11 Concurrency Control
 Example: Bank Balances
 Transaction A: retrieves some record R at time t1
 Transaction B: retries the same record R at time t2
 Transaction A: updates record at time t3 on the
basis of values read at time t1
 Transaction B updates the same record at time t4
on the basis of values read at

t2 which are the same as those at t1

12 Concurrency Control
 Solutions to the Lost Update
Problem
 The loss of Transaction A’s update is avoided by preventing
Transaction B from reading the value of R until after Transaction
A's update has been completed.
 Write Lock R at t1

13 Concurrency Control
 Uncommitted Dependency Problem
 A violation of the integrity constraints governing the database can
arise when two transactions are allowed to execute concurrently
without being synchronized.
 Consider this situation:

Time Transaction A Transaction B

t1 - Write R
t2 Read R -
t3 ROLLBACK

14 Concurrency Control
 Example: Scheduling of Surgeons
for Operations
 Transaction A reads an uncommitted update at time t2 e.g.
assigning Theatre to a Surgeon and a Patient
 The update is then undone at time t3 e.g. Surgeon or the Patient
becomes Unavailable
 Transaction A is therefore operating on false assumption
i.e.Transaction A becomes dependent on an uncommitted update
at time t2

15 Concurrency Control
 Solution to the Uncommitted
Dependency Problem
 The problem is avoided by preventing Transaction A from reading
the value of R until after the decision has been made either to
commit or abort Transaction B's effect.
 Write Lock R at t1

16 Concurrency Control
 Inconsistent Analysis Problem

 Transactions that only read the database can obtain

inaccurate results if they are allowed to read partial
results of incomplete transactions, which are
simultaneously updating the database
 Consider two transactions A and B operating on bank
account records
 Transaction B is summing account balances.
 Transaction A is transferring an amount 10 from
account 1 to account 3
 Account 1 = 100; Account 2 = 50; Account 3 = 25

17 Concurrency Control
 Inconsistent Analysis Problem 2

Time Transaction A Transaction B Acc1 Acc2 Acc3Sum

t1 Read Acc1 Read Acc1 100 50 25 0
t2 Acc1 - 10 Sum + Acc1 100 50 25 100
t3 Write Acc1 Read Acc2 90 50 25 100
t4 Read Acc3 Sum + Acc2 90 50 25 150
t5 Acc3 + 10 - 90 50 25 150
t6 Write Acc3 - 90 50 35 150
t6 Commit Read Acc3 90 50 35 150
t7 - Sum + Acc3 90 50 35 185
t8 - Commit 90 50 35 185

 Sum = 185 not 175!!

18 Concurrency Control
 Solution: Inconsistent Analysis Problem

 The problem is avoided by preventing Transaction B from reading

the balance of Account 1 and Account 3 until after Transaction A
has completed its updates

19 Concurrency Control
 Locking

• If a transaction wants to read an object, it must first request a

shared lock (S mode) on that object
• If a transaction wants to modify an object, it must first request an
exclusive lock (X mode) on that object
• Allow one exclusive lock, or multiple shared locks

20 Concurrency Control
 Locking

Consider the following two transactions

T1 T2
read(x) read(x)
x = x+1 x = x*2
write(x) write(x)
read(y) read(y)
y = y-1 y = y*2
write(y) write(y)
commit commit

21 Concurrency Control
 Locking

The Lock Manager may schedule the tx as follows:

22 Concurrency Control
 Two Phase Locking

 All lock requests precede all unlock requests

 Phase 1: obtain locks
 Phase 2: release locks
T1 T2 T1 T2
r(A) r(A)
w(A) 2PL w(A)
r(A) guarantees a r(A)
w(A) conflict -serializable w(A)
schedule
r(B) r(B)
w(B) w(B)
r(B) r(B)
w(B) w(B)

23 Concurrency Control
 Problem of 2PL
T1 T2  T2 has read uncommitted data
r(A) written by T1
w(A)
r(A)
 If T1 aborts, then T2 must abort as
w(A) well
r(B)  Cascading aborts possible if other
w(B) transactions have read data written
r(B) by T2
r(B)
Abort!
 What’s worse, what if T2 commits
before T1?

24 Concurrency Control
 Strict 2PL

 Only release locks at commit/abort time

– A writer will block all other readers until the writer commits or
aborts
 Used in most commercial DBMS (except Oracle)

25 Concurrency Control
 Deadlocks
Time Transaction A Transaction B
t1 Read Lock ACC1
t2 Read ACC1
t3 sum = sum + ACC1
t4 Read Lock ACC2
t5 Read ACC2
t6 sum = sum + ACC2 Write Lock ACC3
t7 wait Write ACC3
t8 wait Write Lock ACC1
t9 wait wait
t10 wait Wait
t11 wait Wait
Deadlock had occurred!

26 Concurrency Control
 Dealing with Deadlocks

 Impose an order for locking objects

– Must know in advance which objects a transaction will access
 Timeout
– If a transaction has been blocked for too long, just abort
 Prevention
– Idea: abort more often, so blocking is less likely
– Wait/die versus wound/wait
 Detection using wait-for graph
– Idea: deadlock is rare, so only deal it when it becomes an issue
– How often do we detect deadlocks?
– Which transactions do we abort in case of deadlock?

27 Concurrency Control
 Concurrency Control without Locking

 Optimistic (validation-based)
 Timestamp-based

28 Concurrency Control
 Optimistic (validation-based)

 Locking is pessimistic
– Use blocking to avoid conflicts
– Overhead of locking even if contention is low
 Optimistic concurrency control
– Assume that most transactions do not conflict
– Let them execute as much as possible
– If it turns out that they conflict, abort and restart
– Timestamp-based

29 Concurrency Control
 Optimistic: Sketch of Protocol

 Read phase: transaction executes, reads from the database, and

writes to a private space
 Validate phase: DBMS checks for conflicts with other transactions;
if conflict is possible, abort and restart
– Requires maintaining a list of objects read and written by each
transaction
 Write phase: copy changes in the private space to the database

30 Concurrency Control
 Pessimistic vs Optimistic

 Overhead of locking vs overhead of validation and copying private

space
 Blocking versus Aborts and Restarts
 Note
– Locking has better throughput for environments with medium-
to-high contention
– Optimistic concurrency control is better when resource
utilization is low enough

31 Concurrency Control
 Timestamp-based

 Associate each database object with a read timestamp and a write

timestamp
 Assign a timestamp to each transaction (Timestamp order is
commit order)
 When transaction reads/writes an object, check the object’s
timestamp for conflict with a younger transaction; if so, abort and
restart

32 Concurrency Control