Chapter 3:

Transaction Processing Concepts

Concurrency Control & Recovery

Database System Concepts, 5th Ed.

©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use
 Chapter 3 (Objectives)
Transaction – Definition Deadlock
Transaction states Recovery concepts
Recovery manager Types of failure
Transaction Log Recovery Facilities
ACID property Recovery techniques
Concurrent Execution Deferred update
Schedules Immediate update
Serializability
Conflict Serializabilty
Recoverabilty
Problems caused by concurrent
execution
Concurrency Control
Technique.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.2 ©Silberschatz, Korth and Sudarshan
 Transaction Concept
 A transaction is a unit of program execution that accesses and possibly
updates various data items.
 It is either completed in its entirety or not done at all.
 This logical unit of database processing includes one or more access
operations (read -retrieval, write - insert or update, delete).
 E.g. transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
 Two main issues to deal with:
 Failures of various kinds, such as hardware failures and system
crashes
 Concurrent execution of multiple transactions

Database System Concepts - 5th Edition, Sep 12, 2006. 15.3 ©Silberschatz, Korth and Sudarshan
 Database State

 A successful transaction changes the database from one

consistent state to another.

 A consistent database state is one in which all data integrity

constraints are satisfied.

 If the database is not in a consistent state, the transaction will yield

an inconsistent database that violates its integrity and business

rules.

 All transactions are controlled and executed by the DBMS to

guarantee database integrity.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.4 ©Silberschatz, Korth and Sudarshan
  Although a SELECT query in SQL does not

make any changes in the table, the SQL

code represents a transaction because it
accesses the database.

 A transaction may consist of a single SQL

statement or a collection of related SQL

statements.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.5 ©Silberschatz, Korth and Sudarshan
 Transaction Concept
 A transaction can have one of two outcomes:

 Committed : If a transaction completed successfully and

the database reaches a new consistent state.

 Aborted : If the transaction does not executed successfully.

 The database must be restored to the consistent state it

was, before the transaction started. Such a transaction is
called rolled back or undone.

 For recovery purposes, the system needs to keep track of when

the transaction starts, terminates, and commits or aborts.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.6 ©Silberschatz, Korth and Sudarshan
 Concurrent Executions-advantages

 Multiple transactions are allowed to run

concurrently in the system. Advantages are:
 increased processor and disk utilization,
leading to better transaction throughput
 E.g. one transaction can be using the CPU
while another is reading from or writing to the
disk
 reduced average response time for
transactions: short transactions need not wait
behind long ones.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.7 ©Silberschatz, Korth and Sudarshan
 Database Concurrency Control
Concurrency Control : A process of managing simultaneous
operation in a database with out having them interfere with one
another.
Need of concurrency
 Enables many users to access shared data concurrently.
 Similar objective with multi-user computer system
 Improve throughput- (the amount of work accomplished in a given
time interval)
Purpose of Concurrency Control
 To enforce Isolation (through mutual exclusion) among
conflicting transactions.

To preserve database consistency through consistency
preserving execution of transactions.
Concurrency Control Schemes – mechanisms to achieve isolation.
 that is, to control the interaction among the concurrent transactions in order to
prevent them from destroying the consistency of the database

Database System Concepts - 5th Edition, Sep 12, 2006. 15.8 ©Silberschatz, Korth and Sudarshan
 Potential Problems Caused By Concurrency

 The lost update problem

 Occurs when a transaction successfully completed by one

user can be overridden by another user.
 Uncommitted dependency problem (Temporary Update or
Dirty Read Problem)
 Occurs when one transaction is allowed to see the
intermediate result of another transaction which is not
committed.
 Inconsistent analysis problem (Incorrect Summary Problem)

 Occurs when a transaction read several values from the

database but a second transaction updates some of the them
during the execution of the first.

9
Database System Concepts - 5 Edition, Sep 12, 2006.
th
15.9 ©Silberschatz, Korth and Sudarshan
 Lost Update problem - Example
 Assume that you have a product whose current
quantity value is 35.
 Also assume that two concurrent transactions, T1 and
T2, occur that update the quantity value for some item in
the database.
 The transactions are as below:

Transaction Computation
T1: Buy 100 units quantity =quantity +100
T2 : Sell 30 units quantiity=qunatitiy-30

Database System Concepts - 5th Edition, Sep 12, 2006. 15.10 ©Silberschatz, Korth and Sudarshan
  Following table shows the serial execution of
those transactions under normal circumstances,
yielding the correct answer quantity = 105.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T2 Read quantity 135
5 T2 quantity =135-30
6 T2 Write quantity 105

Database System Concepts - 5th Edition, Sep 12, 2006. 15.11 ©Silberschatz, Korth and Sudarshan
  If a transaction is able to read a product’s quantity
value from the table before a previous transaction
(using the same product) has been committed.
 The sequence depicted below shows how the lost
update problem can arise.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T2 Read quantity 35
3 T1 quantity =35 +100
4 T2 quantity =35-30
5 T1 Write quantity 135
6 T2 Write quantity 5 (Lost update)

Database System Concepts - 5th Edition, Sep 12, 2006. 15.12 ©Silberschatz, Korth and Sudarshan
 Uncommitted Data - Example
 Assume that you have a product whose current quantity
value is 35.
 Also assume that two concurrent transactions, T1 and T2,
occur that update the quantity value for some item in the
database.
 T1 is forced to roll back due to an error. T1 transaction is
rolled back to eliminate the addition of the 100 units. Because
T2 subtracts 30 from the original 35 units, the correct answer
should be 5.
 The transactions are as below:

Transaction Computation
T1: Buy 100 units quantity =quantity +100
T2 : Sell 30 units quantiity=qunatitiy-30

Database System Concepts - 5th Edition, Sep 12, 2006. 15.13 ©Silberschatz, Korth and Sudarshan
  Following table shows the serial execution of
those transactions under normal circumstances,
yielding the correct answer quantity = 5.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T1 Rollback 135
5 T2 Read quantity 35
6 T2 quantity =35-30
7 T2 Write quantity 5

Database System Concepts - 5th Edition, Sep 12, 2006. 15.14 ©Silberschatz, Korth and Sudarshan
  Following table shows how the uncommitted data
problem can arise when the ROLLBACK is completed
after T2 has begun its execution.

Time Transaction Step Stored Value

1 T1 Read quantity 35
2 T1 quantity =35 +100
3 T1 Write quantity 135
4 T2 Read quantity 135
(Reading
uncommitted data)
5 T2 quantity =135-30
6 T1 ROLLBACK 35
7 T2 Write quantity 105

Database System Concepts - 5th Edition, Sep 12, 2006. 15.15 ©Silberschatz, Korth and Sudarshan
 Example : Inconsistence Analysis Problem
T1 T2
Sum  0
If one transaction is calculating
Read(A)
an aggregate summary function sumsum+A
on a number of records while ………..

other transactions are updating Read(X) ………….

XX-N
some of those records ,the
Write(X)
aggregate function may calculate Read(X)
some values before they are sumsum+X
updated and others after they are Read(Y)

updated. sumsum+Y
Read(Y)
YY+N
Write(Y)

How do we avoid Inconsistence analysis problem?

Preventing T2 from reading values until after T1 has completed its update 16
Database System Concepts - 5 Edition, Sep 12, 2006.
th
15.16 ©Silberschatz, Korth and Sudarshan
 Recovery Concepts
 Database recovery : the processes of restoring the database to a correct state in
the event of a failure. It is a service provided by the DBMS to ensure that the database
is reliable and remains in a consistent state in the presence of failure.
 Types of Failures:
 A computer failure (System crashes): A hardware, software or
network error occurs in the computer system during transaction
execution. Hardware crashes are usually media failures – for
example main memory failure.
 A transaction or system error: Some operations in the
transaction such as integer overflow or division by zero or logical
programming error may cause it to fail.
 Local errors or exception conditions detected by the
transaction: certain conditions that may occur that necessitate
cancellation of transaction. This exception should be programmed
in the transaction itself & hence would not be considered a failure.
 Concurrency Control Enforcement: the concurrency control
method may decide to abort the transaction, to be restarted later,
because it violates serializability or because several transactions
are in a state of deadlock.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.17 ©Silberschatz, Korth and Sudarshan
 Transaction Concept
 Transaction states:

1. Active state
2. Partially committed state
3. Committed state
4. Failed state
5. Terminated State

Database System Concepts - 5th Edition, Sep 12, 2006. 15.18 ©Silberschatz, Korth and Sudarshan
 State transition diagram illustrating the
states for transaction execution

Database System Concepts - 5th Edition, Sep 12, 2006. 15.19 ©Silberschatz, Korth and Sudarshan
 Transaction State
1. A transaction goes into an active state immediately after
it starts execution where it can issue READ or WRITE
operations.
2. When the transaction ends, it moves to the partially
committed state where certain recovery protocols
ensures that a system failure will not result in an inability
to record the changes of the transaction permanently.
(Changes are recorded in TRANSACTION LOG)
a. If this check is successful the transaction enters into
a commit point and enters the committed state. If
so, all its changes must be recorded permanently in
the database.
b. If this check fails, it goes to the failed state.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.20 ©Silberschatz, Korth and Sudarshan
 Transaction State

4. Transaction can go the failed state, from the partially

committed state if any of the checks there fails or if the

transaction is aborted from its active state itself.

a. The transaction may then have to be rolled back to

undo the effect of WRITE operations.

5. The terminated state corresponds to the transaction

leaving the system.

6. Failed or Aborted transactions may be restarted later

either automatically or after being resubmitted by the

user.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.21 ©Silberschatz, Korth and Sudarshan
 ACID Properties

To preserve the integrity of data the

database system must ensure:
1. Atomicity (“all” or “nothing” property)
2. Consistency
3. Isolation
4. Durability

Database System Concepts - 5th Edition, Sep 12, 2006. 15.22 ©Silberschatz, Korth and Sudarshan
 ACID Properties
 Atomicity

 A transaction is treated as a single, indivisible, logical

unit of work.

 If a transaction T1 has four SQL requests, all four

requests must be successfully completed;
otherwise,the entire transaction is aborted.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.23 ©Silberschatz, Korth and Sudarshan
 ACID Properties
 Consistency

 A complete & correct execution of the transaction

must take the database from one consistent state to
another.

 Execution of a transaction in isolation preserves the

consistency of the database.

 If any of the transaction parts violates an integrity

constraint, the entire transaction is aborted.

 A DBMS program should be written in a way that no

inference from other transaction occurs.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.24 ©Silberschatz, Korth and Sudarshan
 ACID Properties
 Isolation

 A transaction should not make its updates visible to

other transactions until it is committed;

 If a transaction T1 is being executed and is using

the data item X, that data item cannot be accessed
by any other transaction (T2 ... Tn) until T1 ends.

 This property is particularly useful in multiuser

database environments because several users can
access and update the database at the same time.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.25 ©Silberschatz, Korth and Sudarshan
 ACID Properties
 Durability

 After a transaction completes successfully, the

changes it has made to the database persist, even if
there are system failures.

 The changes applied to the database by a

committed transaction must persist in the database.
These changes must not be lost because of any
failure.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.26 ©Silberschatz, Korth and Sudarshan
  When executing multiple transactions, the DBMS must

schedule the concurrent execution of the transaction’s

operations.

 The schedule of such transaction’s operations must

exhibit the property of serializability. (not an issue in

single transaction.)

 Serializability ensures that the schedule for the

concurrent execution of the transactions yields consistent

results. This property is important in multiuser and
distributed databases, where multiple transactions are
likely to be executed concurrently.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.27 ©Silberschatz, Korth and Sudarshan
 Example of Fund Transfer
 Transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
 Atomicity requirement
 if the transaction fails after step 3 and before step 6, money will be “lost”
leading to an inconsistent database state
 Failure could be due to software or hardware
 the system should ensure that updates of a partially executed transaction
are not reflected in the database. The recovery technique must undo any
effects of the transaction on 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.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.28 ©Silberschatz, Korth and Sudarshan
 Example of Fund Transfer (Cont.)
 Transaction to transfer $50 from account A to account B:
1. read(A)
2. A := A – 50
3. write(A)
4. read(B)
5. B := B + 50
6. write(B)
 Consistency requirement in above example:
 the sum of A and B is unchanged by the execution of the
transaction
 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.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.29 ©Silberschatz, Korth and Sudarshan
 Example of Fund Transfer (Cont.)
 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).

T1 T2
1. read(A)
2. A := A – 50
3. write(A)
read(A), read(B), print(A+B)
4. read(B)
5. B := B + 50
6. write(B
 Isolation can be ensured trivially by running transactions serially
 that is, one after the other.
 However, executing multiple transactions concurrently has significant
benefits.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.30 ©Silberschatz, Korth and Sudarshan
 Transaction Management with SQL
 The (ANSI) has defined standards that govern SQL
database transactions.
 Transaction support is provided by two SQL statements:
COMMIT and ROLLBACK.
 A COMMIT statement
 A ROLLBACK statement

Database System Concepts - 5th Edition, Sep 12, 2006. 15.31 ©Silberschatz, Korth and Sudarshan
 Transaction Log
 A DBMS uses a transaction log to keep track of all
transactions that update the database.
 The information stored in this log is used by the DBMS for a
recovery requirement triggered by a ROLLBACK statement,
a program’s abnormal termination, or a system failure such
as a network discrepancy or a disk crash.
 After a server failure, for example, Oracle automatically rolls
back uncommitted transactions and rolls forward transactions
that were committed but not yet written to the physical
database.
 This behavior is required for transactional correctness and is
typical of any transactional DBMS.
 Using a transaction log increases the processing overhead of
a DBMS; but have the ability to restore a corrupted database.
 .
Database System Concepts - 5th Edition, Sep 12, 2006. 15.32 ©Silberschatz, Korth and Sudarshan
 Transaction Log
 While the DBMS executes transactions that modify the
database, it also automatically updates the transaction
log. The transaction log stores:
 A record for the beginning of the transaction.
 For each transaction component (SQL statement):
 The type of operation being performed (update,
delete, insert).
 The names of the objects affected by the transaction
(the name of the table).
 The “before” and “after” values for the fields being
updated.
 Pointers to the previous and next transaction log
entries for the same transaction.
 The ending (COMMIT) of15.33
the transaction.
Database System Concepts - 5th Edition, Sep 12, 2006. ©Silberschatz, Korth and Sudarshan
 The Scheduler
 As long as two transactions, T1 and T2, access unrelated
data, there is no conflict and the order of execution is
irrelevant to the final outcome.
 But if the transactions operate on related (or the same)
data, conflict is possible among the transaction
components and the selection of one execution order
over another might have some undesirable
consequences.
 So how is the correct order determined, and who
determines that order?
 The DBMS handles that tricky assignment by using a
built-in scheduler.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.34 ©Silberschatz, Korth and Sudarshan
 The Scheduler

 The scheduler is a special DBMS process that establishes

the order in which the operations within concurrent

transactions are executed.

 The scheduler interleaves the execution of database

operations to ensure serializability and isolation of

transactions.

 To determine the appropriate order, the scheduler bases its

actions on concurrency control algorithms, such as locking

or time stamping methods.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.35 ©Silberschatz, Korth and Sudarshan
 Schedules
 Schedule – a sequences of instructions that specify the
chronological order in which instructions of concurrent
transactions are executed.
 When transactions are executing concurrently in an interleaved
fashion, the order of execution of operations from the various
transactions, forms what is known as a transaction schedule (or
history).
 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
 A transaction that fails to successfully complete its execution will
have an abort instruction as the last statement

Database System Concepts - 5th Edition, Sep 12, 2006. 15.36 ©Silberschatz, Korth and Sudarshan
 Serial & Non-Serial Schedules
 Serial schedule:

 A schedule S is serial if, for every transaction T

participating in the schedule, all the operations of T are
executed consecutively in the schedule.

 That is operations of each transaction are executed

consecutively, without any interleaved operations from
the other transaction.
 In a serial transaction, entire transactions are performed in
serial order. Eg: If we have two transactions T1 & T2, serial
order would be T1 followed by T2, or T2 followed by T1.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.37 ©Silberschatz, Korth and Sudarshan
 Serial & Non-Serial Schedules

 Non-Serial schedule:

 The schedule that is not serial is called non-serial

schedule.

 Here each sequence interleaves operations from

the two transactions.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.38 ©Silberschatz, Korth and Sudarshan
 Schedule 1
 Let T transfer $50 from A to B, and T transfer 10% of the
1 2
balance from A to B.
 A serial schedule in which T1 is followed by T2 :

Database System Concepts - 5th Edition, Sep 12, 2006. 15.39 ©Silberschatz, Korth and Sudarshan
 Schedule 2
• A serial schedule where T2 is followed by T1

Database System Concepts - 5th Edition, Sep 12, 2006. 15.40 ©Silberschatz, Korth and Sudarshan
 Serial & Non-Serial Schedules

 In serial execution there is no interference

between transactions, because only one is executing
at any given time.
 so, it prevents the occurrence of concurrency
problems.

 Serial schedule never leave the database in an

inconsistent t sate, so every serial schedule is
considered correct.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.41 ©Silberschatz, Korth and Sudarshan
 Schedule 3(Non Serial)
 Let T and T be the transactions defined previously. The following
1 2
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.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.42 ©Silberschatz, Korth and Sudarshan
 Schedule 4
 The following concurrent schedule (nonserial) does not
preserve the value of (A + B ).

Database System Concepts - 5th Edition, Sep 12, 2006. 15.43 ©Silberschatz, Korth and Sudarshan
 Serializable Schedule
 The scheduler interleaves the execution of database
operations to ensure serializability and isolation of
transactions.
 A serializable schedule is a schedule of a transaction’s
operations in which the interleaved execution of the
transactions (T1, T2, T3, etc.) yields the same results as
if the transactions were executed in serial order (one after
another).
 The scheduler also makes sure that the computer’s central
processing unit (CPU) and storage systems are used efficiently.
 Additionally, the scheduler facilitates data isolation to ensure that
two transactions do not update the same data element at the
same time.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.44 ©Silberschatz, Korth and Sudarshan
 The objectives of Serializability:
 To determine which of the non serial schedules always give a correct
result and which may give erroneous result.
 The concept used to characterize schedules in this manner is that of
serializability of a schedule.
 To prevent inconsistency from transactions interfering with one
other, it is essential to guarantee serializability of concurrent
transactions.
 A schedule S of n transactions is serializable if it is
equivalent to some serial schedule of the same n
transactions.
 Being serializable implies that the schedule is a correct schedule.
 It will leave the database in a consistent state.
 The interleaving is appropriate and will result in a state as if the
transactions were serially executed, yet will achieve efficiency due
to concurrent execution.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.45 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability
 Two schedules are said to be conflict equivalent if the order of
any two conflicting operations is the same in both schedules.
 Two operations are said to conflict

 If they belong to different transactions

 Access the same database item
 Atleast one of the two operations is a write operation.
 If two conflicting operations are applied in different orders in two
schedules, the effect can be different on the database or on
other transactions in the schedule, and hence the schedules are
not conflict equivalent.
 Different forms of schedule equivalence give rise to the notions
of : conflict serializability

Database System Concepts - 5th Edition, Sep 12, 2006. 15.46 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability

 If a schedule S can be transformed into a schedule

S´ by a series of swaps of non-conflicting

instructions, we say that S and S´ are conflict
equivalent.

 We say that a schedule S is conflict serializable if

it is conflict equivalent to a serial schedule.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.47 ©Silberschatz, Korth and Sudarshan
 Conflict Serializability (Cont.)
 Schedule 1 can be transformed into Schedule 2, a serial
schedule where T2 follows T1, by series of swaps of non-
conflicting instructions.
 Therefore Schedule 1 is conflict serializable.

Schedule 1 Schedule 2
Database System Concepts - 5th Edition, Sep 12, 2006. 15.48 ©Silberschatz, Korth and Sudarshan
 Characterizing Schedules based on
Recoverability

 Recoverable schedule:

 A schedule S is recoverable if no transaction T in S

commits until all transactions T’ that have written an
item that T reads, have committed.

 A schedule in which for each pair of transaction Ti

and Tj ,if Tj reads a data item previously written by
Ti, then the commit operation of Ti precede the
commit operation of Tj.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.49 ©Silberschatz, Korth and Sudarshan
 Example: Unrecoverable schedule
Time T1 T2
T1 begin_transaction
T2 read(balx)
T3 balx=balx+100 begin_transaction
T4 write(balx) read(balx) .. (read undone)
T5 balx=balx*10
T6 write(balx)
T7 read(baly)
T8 baly=baly*10
T9 write(baly)
T10 commit
T11 read(baly)
T12 baly=baly-100
T13 write(baly)
T14 rollback

Database System Concepts - 5th Edition, Sep 12, 2006. 15.50 ©Silberschatz, Korth and Sudarshan
 Concurrency Control
 A policy in which only one transaction can execute at a

time generates serial schedules, but provides a poor

degree of concurrency.
 A database must provide a mechanism that will ensure

that all possible schedules are

 conflict serializable and recoverable
 Concurrency-control protocols allow concurrent

schedules, but ensure that the schedules are conflict

serializable, and are recoverable

Database System Concepts - 5th Edition, Sep 12, 2006. 15.51 ©Silberschatz, Korth and Sudarshan
 Objective Of a Concurrency Control Protocol

 To schedule transactions in such a way as to avoid

any interference between them and hence prevent
the type of problems caused by concurrency.

 One obvious solution is to allow only one

transaction to execute at a time:
 One transaction is committed before the next
transaction is allowed to begin.
 However, the aim of a multi-user DBMS is to
maximize the degree of concurrency.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.52 ©Silberschatz, Korth and Sudarshan
 Concurrency Control Techniques
 Most of these techniques ensure serializability of schedules using
protocols that guarantee serializability.
 The two main concurrency control techniques:
 Locking
 Timestamping
 Locking
 A procedure to control concurrent access to data. When one
transaction is accessing the database, the lock may deny access to
other transactions .
 A lock is a control placed in the database to reserve data so that only
one database user may update it.
 When data is locked, no other database session can update the data
until the lock is released. Any other session that attempts to update
locked data will be placed in a lock wait state.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.53 ©Silberschatz, Korth and Sudarshan
 Concurrency Control with Locking
Methods
 A transaction acquires a lock prior to data access;
 The lock is released (unlocked) when the transaction is
completed so that another transaction can lock the data item for
its exclusive use.
 The use of locks based on the assumption that conflict between
transactions is likely to occur is often referred to as pessimistic
locking.
 Most multiuser DBMSs automatically initiate and enforce locking
procedures. All lock information is managed by a lock manager,
which is responsible for assigning and policing the locks used by
the transactions
 Lock Granularity: indicates the level of lock use. Locking can
take place at the following levels: database, table, page, row, or
even field (attribute).

Database System Concepts - 5th Edition, Sep 12, 2006. 15.54 ©Silberschatz, Korth and Sudarshan
 Database Lock

Database System Concepts - 5th Edition, Sep 12, 2006. 15.55 ©Silberschatz, Korth and Sudarshan
 Database Lock
 In a database-level lock, the entire database is locked,

thus preventing the use of any tables in the database by

transaction T2 while transaction Tl is being executed.

 This level of locking is unsuitable for multiuser DBMSs.

 Data access will be very s-l-o-w.

 Transactions T1 and T2 cannot access the same

database concurrently even when they use different

tables.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.56 ©Silberschatz, Korth and Sudarshan
 Table Level

Database System Concepts - 5th Edition, Sep 12, 2006. 15.57 ©Silberschatz, Korth and Sudarshan
 Table Level
 In a table-level lock, the entire table is locked, preventing access

to any row by transaction T2 while transaction T1 is using the table.

 If a transaction requires access to several tables, each table may

be locked.

 However, two transactions can access the same database as

long as they access different tables.

 Table-level locks are less restrictive than database-level locks.

 When different transactions require access to different parts of the

same table & when the transactions would not interfere with each
other this lock is not suitable for multiuser DBMSs.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.58 ©Silberschatz, Korth and Sudarshan
 Page Level

Database System Concepts - 5th Edition, Sep 12, 2006. 15.59 ©Silberschatz, Korth and Sudarshan
 Page level
 In a page-level lock, the DBMS will lock an entire diskpage.

 A diskpage, or page, is the equivalent of a diskblock, is a

directly addressable section of a disk.

 A table can span several pages, and a page can contain several

rows of one or more tables.

 Page-level locks are currently the most frequently used multiuser

DBMS locking method.

 In Figure,T1 &T2 access the same table while locking different

diskpages. If T2 requires the use of a row located on a page that

is locked by T1, T2 must wait until the page is unlocked by T1.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.60 ©Silberschatz, Korth and Sudarshan
 Row level

Database System Concepts - 5th Edition, Sep 12, 2006. 15.61 ©Silberschatz, Korth and Sudarshan
 Row level
 A row-level lock is much less restrictive.

 The DBMS allows concurrent transactions to access different rows of

the same table even when the rows are located on the same page.

 Although the row-level locking approach improves the availability of

data, its management requires high overhead because a lock exists

for each row in a table of the database involved in a conflicting
transaction.

 Modern DBMSs automatically changes a lock from a row-level to a

page-level lock when the application session requests multiple locks

on the same page.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.62 ©Silberschatz, Korth and Sudarshan
 Field level lock

 The field-level lock allows concurrent transactions

to access the same row as long as they require the

use of different fields (attributes) within that row.

 Although field-level locking clearly yields the most

flexible multiuser data access, it is rarely

implemented in a DBMS because it requires an
extremely high level of computer overhead.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.63 ©Silberschatz, Korth and Sudarshan
 Lock Types

 Regardless of the level of locking, the DBMS may

use different lock types:

 Binary

 Shared/exclusive.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.64 ©Silberschatz, Korth and Sudarshan
 Binary Lock
 A binary lock has only two states: locked (1) or unlocked (0).
 Every transaction requires a lock and unlock operation
for each data item that is accessed.
 Such operations are automatically managed and
scheduled by the DBMS; the user does not need to be
concerned about locking or unlocking data items.
 If the end user wants to override the default, the LOCK
TABLE and other SQL commands are available for that
purpose.
 Binary locks are now considered too restrictive to yield
optimal concurrency conditions. For example, the DBMS
will not allow two transactions to read the same database
object even though neither transaction updates the database,
and therefore, no concurrency problems can occur.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.65 ©Silberschatz, Korth and Sudarshan
 Shared/Exclusive Locks

 The labels “shared” and “exclusive” indicate the nature of

the lock.

 An exclusive lock exists when access is reserved

specifically for the transaction that locked the object.

 The exclusive lock must be used when the potential for

conflict exists.

 A shared lock exists when concurrent transactions are

granted read access on the basis of a common lock. A

shared lock produces no conflict as long as all the
concurrent transactions are read-only.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.66 ©Silberschatz, Korth and Sudarshan
 Shared/Exclusive Locks

 A shared lock is issued when a transaction wants to read

data from the database and no exclusive lock is held

on that data item.

 An exclusive lock is issued when a transaction wants to

update (write) a data item and no locks are currently

held on that data item by any other transaction.

 Using the shared/exclusive locking concept, a lock can

have three states: unlocked, shared (read), and exclusive

(write).

Database System Concepts - 5th Edition, Sep 12, 2006. 15.67 ©Silberschatz, Korth and Sudarshan
 Shared/Exclusive Locks
 Shared locks allow several Read transactions to read the same data

item concurrently. E.g: if T1 has a shared lock on X and T2 wants to

X, T2 also obtains a shared lock on X.

 If T2 updates X, an exclusive lock is required by T2 over X.

 The exclusive lock is granted if and only if no other locks are held
on the data item. If a shared or exclusive lock is already held on X
by T1, an exclusive lock cannot be granted to T2 and T2 must wait
to begin until T1 commits.

 This condition is known as the mutual exclusive rule: only one

transaction at a time can own an exclusive lock on the same
object.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.68 ©Silberschatz, Korth and Sudarshan
 Shared/Exclusive
 Increases the lock manager’s overhead.

1. The type of lock held must be known before a lock can be

granted.

2. Three lock operations exist: READ_LOCK (to check the

type of lock), WRITE_LOCK (to issue the lock), and
UNLOCK (to release the lock).

3. The schema has been enhanced to allow a lock upgrade

(from shared to exclusive) and a lock downgrade (from
exclusive to shared).

Database System Concepts - 5th Edition, Sep 12, 2006. 15.69 ©Silberschatz, Korth and Sudarshan
 Two-Phase Locking to Ensure
Serializability
 Two-phase locking defines how transactions acquire

and relinquish locks. Two-phase locking guarantees

serializability, but it does not prevent deadlocks.

 The two phases are:

 A growing phase, in which a transaction acquires all

required locks without unlocking any data. Once all locks

have been acquired, the transaction is in its locked point.

 A shrinking phase, in which a transaction releases all

locks and cannot obtain any new lock.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.71 ©Silberschatz, Korth and Sudarshan
 Two Phase Locking
 The two-phase locking protocol is governed by the

following rules:

1. Two transactions cannot have conflicting locks.

2. No unlock operation can precede a lock operation in the

same transaction.

3. No data are affected until all locks are obtained—that is,

until the transaction is in its locked point.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.72 ©Silberschatz, Korth and Sudarshan
 Two phase locking

Database System Concepts - 5th Edition, Sep 12, 2006. 15.73 ©Silberschatz, Korth and Sudarshan
 Two Phase Locking

 In this figure, the transaction acquires all of the locks it needs

until it reaches its locked point.

 When the locked point is reached, the data are modified to

conform to the transaction’s requirements.

 Finally, the transaction is completed as it releases all of the

locks it acquired in the first phase.

 Two-phase locking increases the transaction processing cost

and might cause additional undesirable effects. One

undesirable effect is the possibility of creating deadlocks

Database System Concepts - 5th Edition, Sep 12, 2006. 15.74 ©Silberschatz, Korth and Sudarshan
 Deadlock

 A deadlock occurs when two transactions wait indefinitely

for each other to unlock data.

 For e.g : the two transactions T1 & T2 are deadlocked when

T1 is on the waiting queue for X, which is locked by T2,

while T2 is on the waiting queue for Y which is locked by
T1. Meanwhile neither T1 nor T2 nor any other transaction
can access items X & Y.

 Deadlocks are possible only when one of the transactions

wants to obtain an exclusive lock on a data item; no

deadlock condition can exist among shared locks.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.75 ©Silberschatz, Korth and Sudarshan
 Handling Deadlocks
 Deadlock prevention. A transaction requesting a new lock is aborted when

there is the possibility that a deadlock can occur. If the transaction is

aborted, all changes made by this transaction are rolled back and all locks
obtained by the transaction are released. The transaction is then
rescheduled for execution. Deadlock prevention works because it avoids the
conditions that lead to deadlocking.

 Deadlock detection. The DBMS periodically tests the database for

deadlocks. If a deadlock is found, one of the transactions (the “victim”) is

aborted (rolled back and restarted) and the other transaction continues.

 Deadlock avoidance. The transaction must obtain all of the locks it needs

before it can be executed. This technique avoids the rolling back of

conflicting transactions by requiring that locks be obtained in succession.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.76 ©Silberschatz, Korth and Sudarshan
 Handling Deadlocks
 The choice of the best deadlock control method to use depends

on the database environment.

 If the probability of deadlocks is lowdeadlock detection If the

probability of deadlocks is high deadlock prevention.

 If response time is not high on the system’s priority

listdeadlock avoidance .

 All current DBMSs support deadlock detection in transactional

databases, while some DBMSs use a blend of prevention and

avoidance techniques for other types of data, such as data
warehouses or XML data.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.77 ©Silberschatz, Korth and Sudarshan
 Concurrency Control Techniques

 Timestamping
 A timestamp is a unique identifier for each transaction,
generated by the system.
 Indicates the relative starting time of a transaction.

 Time stamps must have two properties: uniqueness and

monotonicity. Uniqueness ensures that no equal time
stamp values can exist, and monotonicity ensures that
time stamp values always increase.
 Transactions with smaller timestamps get priority in the event
of conflict.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.78 ©Silberschatz, Korth and Sudarshan
 Timestamping

 Two schemes used to decide which transaction is

rolled back and which continues executing

 Wait/Die

 Wound/Wait Schemes

 (Older the transaction lower the time stamp value

and higher the timestamp the newer the transaction.)

Database System Concepts - 5th Edition, Sep 12, 2006. 15.79 ©Silberschatz, Korth and Sudarshan
Database System Concepts - 5th Edition, Sep 12, 2006. 15.80 ©Silberschatz, Korth and Sudarshan
 Time Stamping
 Using the wait/die scheme:

 If the transaction requesting the lock is the older of the two

transactions, it will wait until the other transaction is
completed and the locks are released.

 If the transaction requesting the lock is the younger of the

two transactions, it will die (roll back) and is rescheduled
using the same time stamp.

 In short, in the wait/die scheme, the older transaction

waits for the younger to complete and release its locks.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.81 ©Silberschatz, Korth and Sudarshan
 Time Stamping
 Using the wound/wait scheme:

 If the transaction requesting the lock is the older of the two

transactions, it will preempt (wound) the younger transaction (by

rolling it back). T1 preempts T2 when T1 rolls back T2. The
younger, preempted transaction is rescheduled using the same
time stamp.

 If the transaction requesting the lock is the younger of the two

transactions, it will wait until the other transaction is completed

and the locks are released.

 In short, in the wound/wait scheme, the older transaction rolls

back the younger transaction and reschedules it.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.82 ©Silberschatz, Korth and Sudarshan
 Time Stamping

 In both schemes, one of the transactions waits for the other

transaction to finish and release the locks.

 Some scenario’s can cause transactions to wait indefinitely,

causing a deadlock.

 To prevent that type of deadlock, each lock request has an

associated time-out value.

 If the lock is not granted before the time-out expires, the

transaction is rolled back.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.83 ©Silberschatz, Korth and Sudarshan
 Concurrency control with Optimistic
(Vaildation)Methods
 The optimistic approach is based on the
assumption that the majority of the
database operations do not conflict.
The optimistic approach requires neither
locking nor time stamping techniques.
Instead, a transaction is executed without
restrictions until it is committed. Using an
optimistic approach, each transaction
moves through two or three phases,
referred to as read, validation, and write.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.84 ©Silberschatz, Korth and Sudarshan
 Optimistic (Vaildation)Methods
 During the read phase, the transaction reads the committed
data items from the database, executes the needed
computations, and makes the updates to a private copy of the
database values. All update operations of the transaction are
recorded in a temporary update file(transaction workspace),
which is not accessed by the remaining transactions.
 During the validation phase, the transaction is validated to
ensure that the changes made will not affect the integrity and
consistency of the database. (to ensure that serializability will
not be violated)If the validation test is positive, the transaction
goes to the write phase. If the validation test is negative, the
transaction is restarted and the changes are discarded.
 During the write phase, the changes are permanently applied
to the database.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.85 ©Silberschatz, Korth and Sudarshan
 Optimistic (Vaildation)Methods

 The optimistic approach is acceptable for most read or query

database systems that require few update transactions.

 Transaction execution proceeds with a minimum of overhead

until the validation phase is reached. If there is little

interference among transcations most will be validated
successfully.

 The technique is called optimistic because they assume that

little interference will occure and hence that there is no need to

do checking during transcation execution.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.86 ©Silberschatz, Korth and Sudarshan
 Database Recovery Management

 Database recovery restores a database from a given state

(usually inconsistent) to a previously consistent state after a

failure. It is a service provided by the DBMS to ensure that
the database is reliable and remains in a consistent state in
the presence of failure.

 Recovery techniques also apply to the database and to the

system after some type of critical error has occurred. Critical

events can cause a database to become nonoperational and
compromise the integrity of the data.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.87 ©Silberschatz, Korth and Sudarshan
 Examples of Critical Events
 Hardware/software failures. A failure of this type could be a hard disk media
failure, a bad capacitor on a motherboard, or a failing memory bank. Other
causes of errors under this category include application program or operating
system errors that cause data to be overwritten, deleted, or lost.
 Human-caused incidents. This type of event can be categorized as
unintentional or intentional.
 An unintentional failure is caused by carelessness by end users. Such
errors include deleting the wrong rows from a table, pressing the wrong
key on the keyboard, or shutting down the main database server by
accident.
 Intentional events are of a more severe nature and normally indicate that
the company data are at serious risk. Under this category are security
threats caused by hackers trying to gain unauthorized access to data
resources and virus attacks caused by disgruntled employees trying to
compromise the database operation and damage the company.
 Natural disasters. This category includes fires, earthquakes, floods, and
power failures.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.88 ©Silberschatz, Korth and Sudarshan
  A transaction or system error: Some operations in the
transaction such as integer overflow or division by zero or
logical programming error may cause it to fail.
 Local errors or exception conditions detected by the
transaction: certain conditions that may occur that
necessitate cancellation of transaction. (Notice that an
exception condition such as insufficient account balance
in a banking database may cause transaction such as
fund withdrawal to be canceled.)This exception should be
programmed in the transaction itself & hence would not
be considered a failure.
 Concurrency Control Enforcement: the concurrency
control method may decide to abort the transaction, to be
restarted later, because it violates serializability or
because several transactions are in a state of deadlock.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.89 ©Silberschatz, Korth and Sudarshan
 Transaction Recovery
 Database transaction recovery uses data in the transaction log

to recover a database from an inconsistent state to a

consistent state.

 Four important concepts that affect the recovery process:

1. The write-ahead-log protocol ensures that transaction logs

are always written before any database data are actually
updated. This protocol ensures that, in case of a failure, the
database can later be recovered to a consistent state, using
the data in the transaction log.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.90 ©Silberschatz, Korth and Sudarshan
 2. Redundant transaction logs (several copies of the transaction
log) ensure that a physical disk failure will not impair the DBMS’s
ability to recover data.

3. Database buffers are temporary storage areas in primary memory

used to speed up disk operations. To improve processing time, the
DBMS software reads the data from the physical disk and stores a
copy of it on a “buffer” in primary memory. When a transaction
updates data, it actually updates the copy of the data in the buffer
because that process is much faster than accessing the physical
disk every time. Later on, all buffers that contain updated data are
written to a physical disk during a single operation, thereby saving
significant processing time.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.91 ©Silberschatz, Korth and Sudarshan
 4. Database checkpoints are operations in which the

DBMS writes all of its updated buffers to disk.

While this is happening, the DBMS does not

execute any other requests. A checkpoint operation
is also registered in the transaction log.

As a result of this operation, the physical database

and the transaction log will be synchronized.

Checkpoints are automatically scheduled by the

DBMS several times per hour.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.92 ©Silberschatz, Korth and Sudarshan
 Recovery Technique

 The particular recovery procedures to be used is dependent

on the extent of the damage that has occurred to the

database.

 Two techniques for recovery for the cases where the

database has not been destroyed but is in an inconsistent

state are:

1. Deferred Update. (deferred-write technique)

2. Immediate Update.(write-through techniques)

Database System Concepts - 5th Edition, Sep 12, 2006. 15.93 ©Silberschatz, Korth and Sudarshan
 Recovery Techniques
 DEFERRED UPDATE (deferred-write):

 A transaction cannot change the database on the

disk until it reaches its commit point.
 A transaction does not reach its commit point until
all its update operations are recorded in the log
and the log is force written to disk.
 There is never a need to UNDO any operation
here.
 REDO is needed in case the system fails after a
transaction commits but before all its changes are
recorded in the database on disk.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.94 ©Silberschatz, Korth and Sudarshan
 The Recovery Process For All Started And Committed
Transactions:
1. Identify the last checkpoint in the transaction log. (last time
transaction data was physically saved to disk.)
2. For a transaction that started and was committed before the
last checkpoint, nothing needs to be done because the data are
already saved.
3. For a transaction that performed a commit operation after the
last checkpoint, the DBMS uses the transaction log records to
redo the transaction and to update the database, using the
“after” values in the transaction log.The changes are made
in ascending order, from oldest to newest.
4. For any transaction that had a ROLLBACK operation after the
last checkpoint or that was left active (with neither a COMMIT
nor a ROLLBACK) before the failure occurred, nothing needs to
be done because the database was never updated.

Database System Concepts - 5th Edition, Sep 12, 2006. 15.95 ©Silberschatz, Korth and Sudarshan
 Recovery Techniques
IMMEDIATE UPDATE (write through)
 When a transaction issues an update command, the database
can be updated immediately, without any need to wait for the
transaction to reach its commit point.
 If the recovery technique ensures that all updates of a
transaction are recorded in the database on disk before the
transaction commits, there is no need to redo any operations
of committed transactions.
 Provision for undoing the effect of update operations that have
been applied to the database by a failed transaction.
 It is possible that a transaction might have completed
execution and ready to commit but this transaction is also
undone. Such cases has to 15.96
undergo redo.
Database System Concepts - 5th Edition, Sep 12, 2006. ©Silberschatz, Korth and Sudarshan
 The recovery process:
 Identify the last checkpoint in the transaction log.
 For a transaction that started and was committed before the last
checkpoint, nothing needs to be done because the data are
already saved.
 For any transaction that had a ROLLBACK operation after the last
checkpoint or that was left active (with neither a COMMIT nor a
ROLLBACK) before the failure occurred, the DBMS uses the
transaction log records to ROLLBACK or undo the operations,
using the “before” values in the transaction log. Changes are
applied in reverse order, from newest to oldest.
 For a transaction that was committed after the last checkpoint

(It is possible that a transaction might have completed execution

and ready to commit but this transaction is also undone.), the
DBMS redoes the transaction, using the “after” values of the
transaction log. Changes are applied in ascending order, from
oldest to newest.
Database System Concepts - 5th Edition, Sep 12, 2006. 15.97 ©Silberschatz, Korth and Sudarshan
 End of Chapter 3

Edited : Mrs.Pravicha.M.T
Database System Concepts, 5th Ed.
©Silberschatz, Korth and Sudarshan
See www.db-book.com for conditions on re-use