Lesson 10: Database transactions and concurrency control

10.1. Introduction
In our previous lesson we discussed physical database design. In our lesson
today, we will learn transaction management. Transaction management
deals with the problem of always keeping the database in a consistent state
even when concurrent accesses and failures occur. The important point is
that the database should be consistent when the transaction terminates.
10.2. Lesson objectives
By the end of this lesson, the learner will be able to:
 Understand transaction basics: definition, ACID properties and
transaction states.
 Understand the objective and tools of concurrency control
 Understand failure types and the tools used in recovery management
 Gain insight about transaction design issues.
 Appreciate the role of transaction management in the larger area of
workflow management
10.3. Lesson outline
This lesson is structured as follows:
10.1. Introduction
10.2. Lesson objectives
10.3. Lesson outline
10.4. Transaction
10.5. Transaction properties
10.6. Transaction states
10.7. Transaction execution
10.8. Interference between concurrent transactions
10.9. Concurrency control
10.10. Lock based protocols
10.11. Types of locks
10. 12. Revision questions
10.13. Summary
10.14. Suggested reading
10.4. Transaction
A transaction is a series of operations carried out by a single user or
application program that must be treated as a logical unit of work. A
transaction transforms the database from one consistent state to another
consistent state.
Example
Begin
EXECSQL UPDATE Sales
SET Cost=Cost*1.2
WHERE FirstName=’James’
End
10.5. Transaction properties
To ensure the integrity of data the four transaction properties must be
fulfilled by any transaction.
[a]. Atomicity – This property ensures that for each transaction, either the
effects of all or none of its operations remain when a transaction is
completed (committed or aborted respectively). Transactions are never
left partially executed.
[b]. Consistency –This property requires that every transaction must leave
the database in a consistent (correct) state, i.e., maintain the
predetermined integrity rules of the database. A transaction must
transform a database from one consistent state to another consistent
state.
[c]. Isolation - Transactions cannot interfere with each other. Transactions
must behave as if they were executed in isolation.
[d]. Durability - Effects of successful (committed) transactions must persist
through crashes. Typically achieved by recording the transaction's effects
and its commit event in a non-volatile memory.
10.6. Transaction states
[i]. Active: This is the initial sate: the transaction is in this state when it is
executing.
[ii]. Partially committed: The state after the last statement has been
executed.
[iii]. Committed: The state after successful completion.
[iv]. Failed: State after discovery that a normal execution is no longer
possible. Can be as a result of logical error (e.g. bad input), system
error(e.g. deadlock) or system crash.
COMMIT
START TRANS END
TRANS

Partially Commit
committ ted
ed
Abort
Active

Fail
Aborte
d

ABORT ROLLBACK

10.7. Transaction executions.

Transaction executions can be classified as:
a) Serial execution: Each operation within a transaction can be
executed atomically. T1,……,Tn. This method produces best result but
is slow.
 b) Parallel execution: Several transactions executing simultaneously.
While it improves the throughput, resource utilization and response
time. But too much parallelism can lead to wrong results.
10.8. 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 database.
a) Lost (buried) update problem
This problem occurs when a successfully completed update operation by one transaction is
overwritten by another transaction. Consider the example below:
Time Transactio Transactio
nA nB
T1 Read R -
T2 - Read R
T3 Write R -
T4 - Write R
Thus transaction A’s update is lost at time T4 because transaction B
overwrites it without even looking at it (Without reading R).
Example: Bank balances
Time Transaction A Transaction B
T1 Retrieve Record -
T2 - Retrieve the same record
T3 Update the record on the basis -
of values read at T1
T4 - Update the record on the basis
of values read at T2

Solution to lost update problem.

The lose 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. Thus write lock R at T1.
b) Uncommitted dependency (Dirty read)problem
This is a violation of the integrity constraints governing the database that arise when two transactions
are allowed to execute concurrently without being synchronized. One of the transaction will read value
being updated by another transaction before it has been committed.
Tim Transaction Transaction B
e A
T1 - Write R
T2 Read R -
T3 - ROLLBACK
Example: Bank balances.
Tim Transaction Transaction B
e A
T1 - Calculate discount as 5% for cost Ksh
1000
 T2 Read -
discount
T3 - ROLLBACK
Transaction A is operating on false assumption that discount ( 0.05 X 1000)
still exists! That is transaction A becomes dependent on uncommitted
update at time T2.

Solution to uncommitted dependency problem.

The problem is avoided by preventing transaction A from reading the value
of R until after the decision has been made to commit or abort transaction
B’s effect. Thus write lock R at T1.
c) Inconsistent analysis (Non-repeatable read) 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 A is transferring an amount 10 from account1 to account3.
Initially account1=100, account2=50 and account3=25.
Tim Transacti Transacti Acc1 Acc Acc Sum
e on A on B 2 3
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 35 150
T6 Write Acc3 - 90 50 35 150
T7 Commit Read Acc3 90 50 35 185
T8 - Sum+Acc3 90 50 35 185
T9 - Commit 90
Notice transaction B produces an inconsistent analysis of 185 instead of 175!
Solution to inconsistent analysis problem
The inconsistent analysis problem can prevented by locking the transaction
doing the analysis until the updates by transaction A are completed. i.e.
Read lock R at T1.
d) Phantom read
Phantom reads occur when an insert or delete action is performed against a
row that belongs to a range of rows being read by a transaction. The
transaction's first read of the range of rows shows a row that no longer exists
in the second or succeeding read, as a result of a deletion by a different
transaction. Similarly, as the result of an insert by a different transaction, the
transaction's second or succeeding read shows a row that did not exist in the
original read.
Initially
EmpN EmpName
o
 E001 James
Keen
E012 Janet Keen
E015 John
Morgan
E023 Mary
Johnson
Transaction B selects all the records where name begins with J at T2.
Transaction A inserts a new record at T5.
Transaction A: INSERT INTO EMPLOYEE (EmpNo,EmpName) VALUES
(‘E003’,’Janet Jackson’)
Transaction B: SELECT* FROM EMPLOYEE WHERE EmpName LIKE ‘J%’
Time Transaction Transaction B
A
T1 Read Read (Employee)
(Employee)
T2 Select records
T3 Insert new
record
T4 Select records
T5
Solution to phantom reads
Phantom reads can be prevented by using serializable isolation level. This
level acquires range locks to prevent read, modification and insert operation
on other transaction until the first transaction gets completed. Key-range
locks protect a range of rows implicitly included in a record set being read by
a transaction while using the serializable transaction isolation level. The
serializable isolation level requires that any query executed during a
transaction must obtain the same set of rows every time it is executed
during the transaction. A key range lock protects this requirement by
preventing other transactions from inserting new rows whose keys would fall
in the range of keys read by the serializable transaction. A key-range lock is
placed on an index, specifying a beginning and ending key value. This lock
blocks any attempt to insert, update, or delete any row with a key value that
falls in the range because those operations would first have to acquire a lock
on the index.
10.9. Concurrency control
Schedule: It is a set of operations performed by transactions in the
database. The order in the schedule is very important.
A schedule consists of all or some of the following operations.
Read(x): Means reading an item from the database.
Write(x): Means writing value of x back to the database.
Commit: At the end of transaction, do all the changes.
Abort: Discard all the changes.
Example: Suppose T , R, W and C represents transaction, Read, write and
commit respectively.
Consider two transactions T1 and T2.
T1: R1(x), W1(x), C1(x)
T2: R2(x), W2(x), C2(x)
These transactions can be interleaved in any order and thus results differ.
e.g. R1(x),W1(x), R2(x),W2(x),C1(x)C2(x).
Such a sequence of operations performed on the database by some
transactions T1…Tn is referred to as a schedule. The transactions keep
continuously executing in the database which means as transactions are
coming, we are executing the read and write operations relating to these
transactions and committing or aborting the transactions at the end of what
they performed and the process continues. Whatever the operations,
transactions must leave the database in a consistent state.
Example: Consider the two schedule below:
Sa=[R1(x),R2(x),W1(x),W2(x),C1(x),C2(x)]
Consider x=10, x=10 after the read operations.
x=5, x=15 after write operations
x=5, x=15 after commit operations.
Thus after commit, the database will be inconsistent (Their results may
differ).

Serial schedule
A schedule where new transaction is only executed after earlier transaction
has completed. Serial schedule is always consistent.
T1: Is consistent from start to finish.
T2: Is consistent from start to finish.
This is possible if T1 executes from start to finish before T2 or vise versa.
Serial schedule is slow. But it is possible to execute two or transactions
concurrently without interfering with each other.

Equivalent schedule
Schedule a and b are said to be equivalent iff;
 T1…Tn operations appear in both schedules.
 Operations that are conflicting appear in the same order.

Serializable schedule
A schedule sa said to be serializable if we are able to transform its
operations to another schedule sb so that the new schedule is equivalent to
original schedule .i.e. conflicting operations if any are in the same order and
sb is a serial schedule.
10.10. Conflicting operations
Two operations on the same data item conflict if at least one of the operations is a write.
Transactio Transactio Conflict?
nA nB
Read(x) Read(x) No
Write(x) Write(x) Yes
Read(x) Write(x) Yes
Write(x) Read(x) Yes
Rea(x) Read(y) No
Write(x) Write(y) No
Read(y) Write(x) No
Write(y) Read(x) No

Serialization of concurrent transactions.

Process of managing the execution of a set of transactions in such a way that
their concurrent execution produces the same end result as if they were run
serially. To eliminate concurrency access problems and to implement
atomicity, consistency, and isolation we need two additional operations
(other than read and write), which are called Lock and Unlock, and are
applied on a data item.

10.11. Lock-Based Protocols

A lock is a mechanism to control concurrent access to a data item. A locking
protocol is a set of rules followed by all transactions while requesting and
releasing locks. Locking protocols restrict the set of possible schedules. Data
items can be locked in two modes:
Exclusive (X) mode. Data item can be both read as well as written. X-lock
is requested using lock-X instruction.
Shared (S) mode. Data item can only be read. S-lock is requested using
lock-S instruction. Transaction can proceed only after request is granted.
A transaction may be granted a lock on an item if the requested lock is
compatible with locks already held on the item by other transactions. Any
number of transactions can hold shared locks on an item, but if any
transaction holds an exclusive on the item no other transaction may hold any
lock on the item. If a lock cannot be granted, the requesting transaction is
made to wait till all incompatible locks held by other transactions have been
released. The lock is then granted.
Lock (X): If a transaction T1 applies Lock on data item X, then X is locked
and it is not
available to any other transaction.
Unlock (X): T1 Unlocks X. Thus X becomes available to other transactions.

10.12. Types of a Lock

a) Shared lock: A Read operation does not change the value of a data
item. Hence a data item can be read by two different transactions
simultaneously under share lock mode. So only to read a
data item T1 will do: Share lock (X), then Read (X), and finally Unlock (X).
b) Exclusive lock: A write operation changes the value of the data item.
Hence two write
operations from two different transactions or a write from T1 and a read from
T2 are not
allowed. A data item can be modified only under Exclusive lock. To modify a
data item T1 will
do: Exclusive lock (X), then Write (X) and finally Unlock (X).
When these locks are applied, then a transaction must behave in a special
way. This special
behavior of a transaction is referred to as well-formed.
Well-formed transaction: A transaction is well- formed if it does not lock a
locked data item and it does not try to unlock an unlocked data item.
10.13. Revision questions
[a]. Briefly explain the meaning of the ACID properties. How do
concurrency control and recovery management support the ACID
properties?
[b]. Briefly explain the meaning of transparency as it relates to computer
processing. Why is transparency important for concurrency control and
recovery management?
[c]. What costs are associated with concurrency control and recovery
management? In what role, database administrator or database
programmer, would you assess these costs?
[d]. What is the objective of concurrency control? How is the measure used
in the objective related to waiting time?
[e]. What is a lock? Briefly explain the differences between shared (S) and
exclusive (X) locks?
[f].What operations are performed by the lock manager?
[g]. What is a deadlock and how do most DBMSs handle deadlocks?
10.14. Summary
To process transactions concurrently, the database server must
execute some component statements of one transaction, then some
from other transactions, before continuing to process further
operations from the first. The order in which the component
operations of the various transactions are interleaved is called the
schedule.
Applying transactions concurrently in this manner can result in many
possible outcomes. Sometimes, the final state of the database also
could have been achieved had the transactions been executed
sequentially, meaning that one transaction was always completed in
its entirety before the next was started. A schedule is called
serializable whenever executing the transactions sequentially, in
some order, could have left the database in the same state as the
actual schedule.
Serializability is the commonly accepted criterion for correctness. A
serializable schedule is accepted as correct because the database is
not influenced by the concurrent execution of the transactions.
The isolation level affects a transaction's serializability. At isolation
level 3, all schedules are serializable. The default setting is 0.
10.15. Suggested reading
[1]. Modern Database Management (6th Edition) Jeffrey A. Hoffer, Mary B.
Prescott, Fred R. McFadden Prentice Hall; 6th edition (2002).
[2]. Database systems: practical approach to design, implementation and
management T Connolly and C Begg (2004) Addison Wesley (2004).
[3]. Database Design: Concepts and Implementation (Mcgrah-Hill Computer
Science Series) Gio Wiederhold McGraw-Hill College; 3rd edition (1992)
[4]. Database System Concepts Abraham Silberschatz, et al McGraw-Hill
Science/Engineering/Math; 4 edition (2001).
[5]. Database Management Systems Raghu Ramakrishnan, et al McGraw-
Hill 3 edition (2002).
[6]. http://dcx.sybase.com/1200/en/dbusage/correct.html
[7]. http://www.slideshare.net/signer/transaction-management
[8]. http://msdn.microsoft.com/en-us/library/
ms191272%28v=sql.105%29.aspx