Overview

of
Transaction Management
Chapter8 (part-1): Overview of Transaction
Management (T2:Page 519-540, 550-555)

 The ACID Properties

 Consistency and Isolation
 Atomicity and Durability
 Transactions and Schedules
 Concurrent Execution of Transactions
 Motivation for Concurrent Execution
 Serializability
 Anomalies due to Interleaved Execution
 Schedules Involving Aborted Transactions
 Chapter8 (part-1): Overview of Transaction
Management (T2:Page 519-540, 550-555)

 Lock-Based Concurrency Control

 Strict Two-Phased Locking
 Deadlocks
 Performance of Locking,
 Transaction Support in SQL
 Creating and Terminating Transactions
 What Should We Lock?
 Transaction Characteristics in SQL
Chapter8 (part-1): Overview of Transaction
Management (T2:Page 519-540, 550-555)

 2PL, Serializability and Recoverability

 View serializability
 Introduction to Lock Management
 Implementing lock and unlock requests
 Overview

 Transaction processing systems are systems with

large databases and hundreds of concurrent users
that are executing database transactions
 Examples:
 Reservation systems
 Banking systems
 They require high availability and fast response
time for hundreds of concurrent users.
 Overview
 A transaction is an execution of a user program,
seen by the DBMS as a series or list of actions i.e.
read and write operations.

 For performance reasons, a DBMS has to

interleave the actions of several transactions.

 The interleaving is done carefully to ensure that the

result of a concurrent execution of transactions
should be equivalent (in its effect upon the
database) to some serial, or one-at-a-time,
execution of the same set of transactions.
 Overview

 Transactions submitted by the various users may

execute concurrently and may access and update
the same database items.

 If this concurrent execution is uncontrolled , it may

lead to problem, such as inconsistent database.

 DBMS handles concurrent executions and it is an

important aspect of transaction management and is
the subject of concurrency control.
 Overview

 DBMS handles partial transactions, or transactions

that are interrupted before they run to normal
completion.

 The DBMS ensures that the changes made by such

partial transactions are not seen by other
transactions and it is the subject of crash recovery.
 Overview

 Thus, two main issues to deal with:

 Failures of various kinds, such as hardware

failures and system crashes: Crash Recovery

 Concurrent execution of multiple transactions:

concurrency control
 The ACID Properties

 There are four important properties of transactions

that a DBMS must ensure to maintain data in the
face of concurrent access and system failures and
these properties are known as ACID properties:

1. Atomicity
2. Consistency
3. Isolation
4. Durability
 Atomicity
 Users should be able to regard the execution of
each transaction as atomic: either all actions are
carried out or none are.
 A transaction is an atomic unit of processing; it is
either performed in its entirety or not performed at
all.
 Users should not have to worry about the effect of
incomplete transactions (when a system crash
occurs).
 The system should ensure that updates of a
partially executed transaction are not reflected in
the database
 Atomicity
 Transactions can be incomplete for three kinds of
reasons:
 The system may crash
 A transaction can be aborted, or terminated by
DBMS
 A transaction may encounter an unexpected
situation and decide to abort
 Thus a DBMS must find a way to remove the effects
of partial transactions from the database, that is, it
must ensure transaction atomicity: either all of a
transaction's actions are carried out, or none are.
 Consistency

 Each transaction must preserve the consistency of

the database. (when no concurrent execution is
present)

 This property is called consistency, and the

DBMS assumes that it holds for each transaction.

 Ensuring this property of a transaction is the

responsibility of the user.
 Consistency

 In general, consistency requirements include

• Explicitly specified integrity constraints such

as primary keys and foreign keys
• Implicit integrity constraints

 A transaction must see a consistent database i.e. a

transaction is consistency preserving if its
complete execution takes the database from one
consistent state to another.
 Consistency

 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
 Consistency (Example)

 Transaction to transfer Rs. 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:
 The sum of A and B is unchanged by the
execution of the transaction
 Isolation

 A transaction should appear as though it is being

executed in isolation from other transactions i.e. the
execution of a transaction should not be interfered
by any other transactions executing concurrently.

 This property is referred to as isolation:

Transactions are isolated, or protected, from the
effects of concurrently scheduling other
transactions.
 Isolation

 The isolation property is ensured by guaranteeing

that even though actions of several transactions
might be interleaved, the net effect is identical to
executing all transactions one after the other in
some serial order.

 For example, if two transactions T1 and T2 are

executed concurrently, the net effect is guaranteed
to be equivalent to executing T1 followed by
executing T2 or executing T2 followed by executing
T1.
 Durability

 Once the DBMS informs the user that a

transaction has been successfully completed, its
effects should persist even if the system crashes
before all its changes are reflected on disk.

 This property is called durability.

 The DBMS component that ensures atomicity and

durability is called the recovery manager
 Durability

 DBMS maintains a record, called the log, of all

writes to the database.

 The log is used to ensure durability: If the system

crashes before the changes made by a completed
transaction are written to disk, the log is used to
remember and restore these changes when the
system restarts.
 Transactions and Schedules

 A transaction is seen by the DBMS as a series, or

list, of actions.
 The actions that can be executed by a transaction
include reads and writes of database objects.
 Transactions and Schedules

 For recovery purposes, the systems need to keep

track of when the transaction starts, terminate, and
commits or aborts.
 Begin_transaction
 Read or write
 End_transaction
 Commit_transaction or Abort_transaction
 Transactions and Schedules

 The action of a transaction T reading an object O is

denoted as RT (O); and writing as WT (O).

 In addition to reading and writing, each transaction

must specify as its final action either commit (i.e.,
complete successfully) or abort (i.e., terminate and
undo all the actions carried out so far).

 AbortT denotes the action of T aborting, and

CommitT denotes T committing.
 Transactions and Schedules

 A schedule is a list of actions (reading, writing,

aborting, or committing) from a set of transactions.

 The order in which two actions of a transaction T

appear in a schedule must be the same as the
order in which they appear in T.

 A schedule represents an actual or potential

execution sequence.
 Transactions and Schedules

 A schedule that contains either an abort or a

commit for each transaction whose actions are
listed in it is called a complete schedule.

 A complete schedule must contain all the actions of

every transaction that appears in it.
 Transactions and Schedules

Serial schedule
 If the actions of different
transactions are not interleaved i.e.
transactions are executed from
start to finish, one by one ,
schedule is serial.
 Basic Assumption is each
transaction preserves database
consistency.
 Thus serial execution of a set of
transactions preserves database
consistency.
 Transactions and Schedules

Serial Transaction as T1; T2 and T2; T1

 Concurrent Execution of Transactions
(Motivation for concurrent execution)

 The DBMS interleaves the actions of different

transactions to improve performance, in terms of
increased throughput or improved response times
for short transactions, but not all interleaving
should be allowed.

 Ensuring transaction isolation while permitting such

concurrent execution is difficult, but is necessary
for performance reasons.
 Concurrent Execution of Transactions
(Motivation for concurrent execution)

 While one transaction is waiting for a page to be

read in from disk, the CPU can process another
transaction.

 Because I/O activity can be done in parallel with

CPU activity in a computer.

 Overlapping I/O and CPU activity reduces the

amount of time disks and processors are idle, and
increases system throughput (the average
number of transactions completed in a given time).
 Concurrent Execution of Transactions
(Motivation for concurrent execution)

 Interleaved execution of a short transaction with a

long transaction usually allows the short transaction
to complete quickly.

 In serial execution, a short transaction could get

stuck behind a long transaction leading to
unpredictable delays in response time, or average
time taken to complete a transaction.
 Serializability

 A serializable schedule over a set S of committed

transactions is a schedule whose effect on any
consistent database instance is guaranteed to be
identical to that of some complete serial schedule
over S.
or
 The database instance that results from executing
the given schedule is identical to the database
instance that results from executing the
transactions in some serial order.
 Thus a (possibly concurrent) schedule is
serializable if it is equivalent to a serial schedule.
 Serializability

 Even though the actions of T1

and T2 are interleaved, the
result of this schedule is
equivalent to running T1 and
running T2.

 T1’s read and write of B is not

influenced by T2’s actions on A,
and the net effect is the same if
these actions are ‘swapped’ to
obtain the serial schedule T1:T2.
 Serializability

 Executing the transactions serially

in different orders may produce
different results, but all are
presumed to be acceptable.
 The DBMS makes no guarantees
about which of them will be the
outcome of an interleaved
execution.
 If T1 and T2 are submitted
concurrently to a DBMS, either of
these schedule could be chosen.
Serializability (Example)
 Serializability (Example)

This schedule is
not a serial
schedule, but it is
equivalent to
Schedule T1;T2.
Serializability (Example)
 Serializability (Example)

This concurrent
schedule does not
preserve the value
of (A + B ).
 Anomalies Due to Interleaved Execution

 There can be three main ways in which a schedule

involving two consistency preserving, committed
transactions could run against a consistent
database and leave it in an inconsistent state.

 Two actions on the same data object conflict if at

least one of them is a write.
 Anomalies Due to Interleaved Execution

 The three anomalous situations can be described

in terms of when the actions of two transactions T1
and T2 conflict with each other:

 Write-read (WR) conflict

 Read-write (RW) conflict
 Write-write (WW) conflict
 Reading Uncommitted Data (WR Conflicts)

 A transaction T2 could read a database object A

that has been modified by another transaction T1,
which has not yet committed.

 Such a read is called a dirty read or Temporary

Update Problem.
 Reading Uncommitted Data (WR Conflicts)

 Consider two transactions T1 and T2, each of which,

run alone, preserves database consistency: T1
transfers Rs.100 from A to B, and T2 increments
both A and B by 10 percent (e.g. annual interest is
deposited into these two accounts).

 Suppose that their actions are interleaved so that (1)

the account transfer program T1 deducts Rs.50 from
account A, then (2) the interest deposit program T2
reads the current values of accounts A and B and
adds 10 percent interest to each, and then (3) the
account transfer program credits Rs.50 to account B.
WR conflict (Example)
 Reading Uncommitted Data (WR Conflicts)

 The result of this schedule is

different from any result that
we would get by running one of
the two transactions first and
then the other.

 The problem can be traced to

the fact that the value of A
written by T1 is read by T2
before T1 has completed all its
changes.
 Unrepeatable Reads (RW Conflicts)

 A transaction T2 could change the value of an

object A that has been read by a transaction T1,
while T1 is still in progress.

 If T1 tries to read the value of A again, it will get a

different result, even though it has not modified A
in the meantime.

 This situation could not arise in a serial execution

of two transactions; it is called an unrepeatable
read.
 Unrepeatable Reads (RW Conflicts)

 Suppose A is available number of copies of a book in

a library.
 A transaction that places an order first reads the A,
checks that it is greater than 0 and decrements it.
 Transaction T1 reads A and finds 1,
 Transaction T2 also reads A, finds 1 and
decrements A to 0
 Transaction T1 then tries to decrements A and
gets error since integrity constraint says A can not
be Zero.
Overwriting Uncommitted Data (WW Conflicts)

 A transaction T2 could overwrite the value of an

object A, which has already been modified by a
transaction T1, while T1 is still in progress.

 This is also known as Lost Update Problem.

Overwriting Uncommitted Data (WW Conflicts)

 Suppose that Harry and Larry are two employees,

and their salaries must be kept equal.
 Transaction T1 sets their salaries to Rs.10000 and
transaction T2 sets their salaries to Rs. 20000.
 If we execute these in the serial order T1 followed
by T2, both receive the salary Rs.20000; the serial
order T2 followed by T1 gives each the salary Rs.
10000.
 Either of these is acceptable from a consistency
standpoint (although Harry and Larry may prefer a
higher salary!).
Overwriting Uncommitted Data (WW Conflicts)

 If we interleave the actions of T1 and T2:

 T1 sets Harry's salary to Rs.10000, T2 sets Larry's
salary to Rs.20000, T2 sets Harry's salary to
Rs.20000 and finally T1 sets Larry's salary to
Rs.10000.
 The result is not identical to the result of either of
the two possible serial executions, and the
interleaved schedule is therefore not serializable.
 It violates the desired consistency criterion that the
two salaries must be equal.
 Schedules Involving Aborted Transactions

 Definition of serializability to include aborted

transactions includes all actions of aborted
transactions are to be undone.

 A serializable schedule over a set S of transactions

is a schedule whose effect on any consistent
database instance is guaranteed to be identical to
that of some complete serial schedule over the set
of committed transactions in S.
Schedules Involving Aborted Transactions

 This definition of
serializability relies on the
actions of aborted
transactions being undone
completely, which may be
impossible in some
situations.
 Schedules Involving Aborted Transactions

 Now, T2 has read a value for A that should never

have been there!
 The aborted transactions' effects are not supposed
to be visible to other transactions.
 If T2 had not yet committed, cascading the abort of
T1 and also aborting T2 can be done.
 This process would recursively abort any transaction
that read data written by T2, and so on.
 But T2 has already committed, and its actions
cannot be undone such a schedule is
unrecoverable.
 Schedules Involving Aborted Transactions

 A recoverable schedule is one in which

transactions commit only after all transactions
whose changes they read, also commit.

 If transactions read only the changes of committed

transactions, not only is the schedule recoverable,
but also aborting a transaction can be
accomplished without cascading the abort to other
transactions.

 Such a schedule is said to avoid cascading aborts.

 Lock-based Concurrency Control

 A concurrency control technique called Strict 2PL

can prevent problem due to aborting the
transaction.

 A DBMS must be able to ensure that only

serializable, recoverable schedules are allowed,
and than no actions of committed transactions are
lost while undoing aborted transactions.

 A DBMS typically uses a locking protocol to achieve

this.
 Lock-based Concurrency Control

 A locking protocol is a set of rules to be followed

by each transaction (and enforced by the DBMS),
in order to ensure that even though actions of
several transactions might be interleaved, the net
effect is identical to executing all transactions in
some serial order.

 Different locking protocols use different types of

locks, such as shared locks or exclusive locks.
 Strict Two-Phase Locking (Strict 2PL)

 The most widely used locking protocol, called Strict

Two-Phase Locking, or Strict 2PL, has two rules:

1. If a transaction T wants to read an object, it first

requests a shared lock on the object.
(or If a transaction T wants to modify an object, it
first requests a exclusive lock on the object.)

2. All locks held by a transaction are released when

the transaction is completed.
 Strict Two-Phase Locking (Strict 2PL)

 A transaction that has an exclusive lock can also

read the object; an additional shared lock is not
required.

 A transaction that requests a lock is suspended

until the DBMS is able to grant it the requested
lock.
 Strict Two-Phase Locking (Strict 2PL)

 The DBMS keeps track of the locks it has granted

and ensures that if a transaction holds an exclusive
lock on an object, no other transaction holds a
shared or exclusive lock on the same object.

 Requests to acquire and release locks can be

automatically inserted into transactions by the
DBMS; users need not worry about these details.
 Strict Two-Phase Locking (Strict 2PL)

 The locking protocol allows only ‘safe’ interleaving

of transactions.
 If two transactions access completely independent
parts of the database, they will be able to
concurrently obtain the locks that they need and
proceed on their ways.
 If two transactions access the same object, and
one of them wants to modify it, their actions are
effectively ordered serially
 Strict Two-Phase Locking (Strict 2PL)

 All actions of one of these transactions (the one

that gets the lock on the common object first) are
completed before (this lock is released and) the
other transaction can proceed.

 Action of a transaction T requesting a shared lock

on object O can be denoted as ST (O)

 Action of a transaction T requesting a exclusive

lock on object O can be denoted as XT (O)
Strict Two-Phase Locking (Strict 2PL)
 Strict Two-Phase Locking (Strict 2PL)

 First, T1would obtain an exclusive lock on A and

then read and write A
 Then, T2 requests a lock on A.
 But this request cannot be granted until T1 releases
its exclusive lock on A and the DBMS therefore
suspends T2.
 T1 now proceeds to obtain an exclusive lock on B,
reads and writes B, then finally commits, at which
time its locks are released.
 T2's lock request is now granted, and it proceeds.
 Strict Two-Phase Locking (Strict 2PL)

 The actions of
different transactions
can be interleaved if
lock is sharable.
 Deadlocks

Example:
 Transaction T1 sets an exclusive lock on object A,
T2 sets an exclusive lock on B, T1 requests an
exclusive lock on B and is queued, and T2 requests
an exclusive lock on A and is queued.
 T1 waiting for T2 to release its lock and T2 is
waiting for T1 to release its locks.
 Such a cycle of transactions waiting for locks to be
released is called as Deadlock.
 These two transactions will make no further
progress.
 Deadlocks

 They hold locks that may be required by other

transactions.
 The DBMS must either prevent or detect and
resolve deadlocks.
 Timeout mechanism can be used to identify
deadlock.
 If a transaction has been waiting too long for a
lock, it is assumed that it is in deadlock and can be
aborted.
 Performance of Locking

 Lock based schemes are designed to resolve conflicts

between transactions and use two basic mechanisms:
blocking and aborting.
 Both mechanism involve a performance penalty:
 blocked transactions may hold locks that force other
transactions to wait
 aborting and restarting a transaction wastes the
work done thus far by that transaction.
 A deadlock represents an extreme instance of blocking
in which a set of transactions is forever blocked unless
one of the deadlocked transactions is aborted by the
DBMS.
 Performance of Locking

 Fewer than 1% of transactions are involved in a

deadlock, and there are relatively few aborts.
 The overhead of locking comes primarily from delays
due to blocking.
How blocking delays affect throughput.
 The first few transactions are unlikely to conflict and
throughput rises in proportion to the number of active
transactions.
 As more and more transactions execute concurrently
on the same number of database objects, the
likelihood of their blocking each other goes up.
 Performance of Locking

 Thus, delays due to blocking increase with the

number of active transactions and throughput
increases more slowly than the number of active
transactions.
 There comes a point when adding another active
transaction actually reduces throughput: the new
transaction is blocked and effectively competes
with existing transactions.
 We say that the system thrashes at this point.
Performance of Locking
 Performance of Locking

 If a database system begins to thrash, the database

administrator should reduce the number of
transactions allowed to run concurrently.

 Thrashing is to be seen to occur when 30% of

active transactions are blocked, and a DBA should
monitor the fraction of blocked transactions to see if
the system is at risk of thrashing.
 Performance of Locking

Throughput can be increased in three ways:

 By locking the smallest sized objects possible
(reducing the likelihood that two transactions need
the same lock).
 By reducing the time that transaction hold locks (so
that other transactions are blocked for a shorter
time).
 By reducing hot spots: A hot spot is a database
object that is frequently accessed and modified
and cause a lot of blocking delays. Hot spots can
significantly affect performance.
 Transaction support in SQL

Creating and Terminating Transactions

 A transaction is automatically started when a user
executes a statement that accesses either the
database or the catalogs, such as a SELECT
query, an UPDATE command, or CREATE table
statement.
 Once a transaction is started other statements can
be executed as part of this transaction until the
transaction is terminated by either a COMMIT
command or a ROLLBACK command.
 Two features for support
 Transaction support in SQL

1. savepoint:
 savepoint allows us to identify a point in a
transaction and selectively roll back operations
carried out after this point.
 This is especially useful if the transaction carries
out what-if kinds of operations and wishes to undo
or keep the changes based on the results.
 In a long running transaction, a series of
savepoints can be defined.
 Transaction support in SQL

 The savepoint command allows us to give each

savepoint a name:
SAVEPOINT< savepoint name >

 A subsequent rollback command can specify the

save point to roll back to
ROLLBACK TO SAVEPOINT < savepoint name >
 Transaction support in SQL (Example)

 If we define three savepoints A, B and C in that

order, and then rollback to A, all operations since A
are undone, including the creation of savepoints B
and C.
 The savepoint A is itself undone when we rollback
to it, and we must re-establish it if we wish to able
to rollback to it again.
 From a locking standpoint, locks obtained after
savepoint, A can be released when we rollback to
A.
 Transaction support in SQL

 Operations between two consecutive savepoints

can be treated as a new transaction.
 The save point mechanism offers advantages:
 We can rollback over several save points.
 We can rollback only the most recent
transaction, which is equivalent to rolling back to
the most recent savepoint.
 The overhead of initiating several transaction is
avoided.
 Transaction support in SQL

2. Chained transaction:
 Even with the use of savepoints, certain
applications might require us to run several
transactions one after the other.
 To minimize, the overhead in such situations, SQL:
1999 introduces another feature, called chained
transactions.
 We can commit or rollback a transaction and
immediately initiate another transaction. This is
done by using the optional key words AND CHAIN
in the COMMIT and ROLLBACK statements.
 What Should We Lock?

 The DBMS can lock objects at different granularities.

 We can lock entire tables or set row-level locks.
 The row-level locks approach is taken in current
systems because it offers much better performance.
 While row-level locking is generally better, the choice of
locking granularity is complicated.
 Thus, a transaction that examines several rows and
modifies those that satisfy some condition might be
best served by setting shared locks on entire table and
setting exclusive locks on those rows it want to modify.
 What Should We Lock?

Following phenomenon is called the phantom problem:

 A transaction retrieves a collection of objects twice

and sees different results, even though it does not
modify any of these tuples, itself.
 To prevent phantoms, the DBMS must conceptually
lock all possible rows with rating = 8 on behalf of
T1.
 One way to do this is to lock the entire table, at the
cost of low concurrency.
 It is possible to take advantage of indexes to do
better.
 Transaction Characteristics in SQL

 In order to give programmers control over the

locking overhead incurred by their transactions,
SQL allows them to specify three characteristics of
a transaction:
 Access mode
 Diagnostic size
 Isolation level.
 The diagnostics size determines the number of
error conditions that can be recorded.
 DIAGNOSTIC SIZE n
 Transaction Characteristics in SQL

 If the access mode is READ ONLY the transaction

is not allowed to modify the database.
 To execute one of INSERT, DELETE, UPDATE,
CREATE commands, the access mode should be
set to READ WRITE.
 For transactions with read only access mode, only
shared locks need to be obtained, thus increase
concurrency.
 Transaction Characteristics in SQL

 The isolation level controls the extent to which a

given transaction is exposed to the actions of other
transactions executing concurrently.
 By choosing one of four possible isolation level
settings, a user can obtain greater concurrency at
the cost of increasing the transaction’s exposure to
other transactions uncommitted changes.
 Transaction Characteristics in SQL

 Isolation level choices are

 READ UNCOMMITTED
 READ COMMITTD
 REPEATABLE READ
 SERIALIZABLE.
Transaction Characteristics in SQL (SERIALIZABLE)

 The highest degree of isolation from the effect of

other transactions is achieved by setting the
isolation level for a transaction T to
SERIALIZABLE.

 This isolation level ensures that T reads only the

changes made by committed transactions.

 And that if T reads a set of values based on some

search condition, this set is not changed by other
transactions until T is complete.
Transaction Characteristics in SQL (SERIALIZABLE)

 In terms of a lock based implementation a

SERIALIZABLE transaction obtains locks before
reading or writing objects.

 Including locks on sets of objects that it requires to

be unchanged and holds them until the end,
according to strict 2PL.
 Transaction Characteristics in SQL
(REPEATABLE READ )

 REPEATABLE READ ensures that T reads only the

changes made by committed transactions and no
value read or written by T is changed by any other
transaction until T is complete.
 However, T could experience the phantom
phenomenon.
 Eg. While T examines all sailors records with rating
= 1 another transaction might add a new such
sailors record, which is missed by T.
 Transaction Characteristics in SQL

 A REPEATABLE READ transaction sets the same

locks as a SERIALIZABLE transaction except that
it does not do index locking, i.e, it locks only
individual objects, not sets of objects.
 Transaction Characteristics in SQL

 READ COMMITTED ensures that T reads only the

changes made by committed transactions, and that
no value written by T is changed by any other
transaction until T is complete.

 However, a value read by T may well be modified

by another transaction while T is still in progress,
and T is exposed to the phantom problem.
 Transaction Characteristics in SQL

 A READ COMMITTED transaction obtains

exclusive locks before writing objects and holds
these locks until the end.

 It also obtains shared locks before reading objects,

but these locks are released immediately, their only
effect is to guarantee that the transaction that last
modified the object is complete.
 Transaction Characteristics in SQL

 A READ UNCOMMITTED transaction does not obtain

shared locks before reading objects.
 This mode represents the greatest exposure to
uncommitted changes of other transactions: so much
so that SQL prohibits such a transaction from making
any changes itself.
 A READ UNCOMMITTED transaction is required to
have an access mode of READ ONLY.
 Since such a transaction obtains no locks for reading
objects and it is not allowed to write objects, it never
makes any lock requests.
 Transaction Characteristics in SQL

 The serializable isolation level is generally the

safest and is recommended for most transactions.

 Some transactions, however can run with a lower

isolation level and the smaller number of locks
requested can contribute to improved system
performance.
 Transaction Characteristics in SQL

 Eg. A statistical query that finds the average sailor

age can be run at the READ COMMITED level or
even the READ UNCOMMITED level, because a
few incorrect or missing values do not significantly
affect the result if the number of sailors is large.

 The isolation level and access mode can be set

using the SET TRANSACTION command.
 Transaction Characteristics in SQL

 Eg. The following command declares the current

transaction to be SERIALIZALE and READ ONLY>

SET TRANSACTION ISOLATION LEVEL

SERIALIZABLE READ ONLY

 When a transaction is started , the default is

SERIALIZABLE and READ WRITE.
 2PL, Serializability, and Recoverability

 Locking protocols guarantee some important

properties of schedules: serializability and
recoverability.
 Two actions from same schedule, from different
transactions conflict if they operate on the same
data object and at least one of them is a write.
 Two schedules are said to be conflict equivalent if
they involve the (same set of) actions of the same
transactions and they order every pair of conflicting
actions of two committed transactions in the same
way.
 2PL, Serializability, and Recoverability

 The outcome of a schedule depends only on the

order of conflicting operations
 We can interchange any pair of nonconflicting
operations without altering the effect of the
schedule on the database.
 A schedule is conflict serializable if it is conflict
equivalent to some serial schedule.
 Every conflict serializable schedule is serializable
 2PL, Serializability, and Recoverability

 However, some serializable

schedules are not conflict
serializable.
 This schedule is equivalent to
executing the transactions T1
T2 T3 serially in the order T1,
T2, T3 (as it looks), but it is not
conflict equivalent to this serial
schedule because the writes of
T1 and T2 are ordered
differently.
 2PL, Serializability, and Recoverability

 It is useful to capture all potential conflicts between

the transactions in a schedule in a precedence
graph, also called a serializability graph.

 The precedence graph for a schedule S contains:

 A node for each committed transaction in S.
 An arc from Ti to Tj if an action of Ti precedes
and conflicts with one of Tj's actions.
2PL, Serializability, and Recoverability
 2PL, Serializability, and Recoverability

 The Strict 2PL protocol allows only serializable

schedules, as is seen from the following two
results:

1. A schedule S is conflict serializable if and only if its

precedence graph is acyclic.

2. Strict 2PL ensures that the precedence graph for

any schedule that it allows, is acyclic
 2PL, Serializability, and Recoverability

 A widely studied variant of Strict 2PL, called Two-

Phase Locking (2PL), relaxes the second rule of
Strict 2PL to allow transactions to release locks before
the end, that is, before the commit or abort action.
For 2PL, the second rule is replaced by the following
rule:
 (2PL) (2) A transaction cannot request additional
locks once it releases any lock.
 Thus, every transaction has a `growing' phase in
which it acquires locks, followed by a `shrinking'
phase in which it releases locks.
 2PL, Serializability, and Recoverability

 Even (nonstrict) 2PL ensures acyclicity of the

precedence graph and therefore allows only
serializable schedules.

 A schedule is said to be strict if a value written by

a transaction T is not read or overwritten by other
transactions until T either aborts or commits.

 Strict schedules are recoverable, do not require

cascading aborts, and actions of aborted
transactions can be undone by restoring the
original values of modified objects.
 Lock Management

 The part of the DBMS that keeps track of the locks

issued to transactions is called the lock manager.
 The lock manager maintains a lock table, which is
a hash table with the data object identifier as the
key.
 The DBMS also maintains a descriptive entry for
each transaction in a transaction table, and
among other things, the entry contains a pointer to
a list of locks held by the transaction.
 Lock Management

 A lock table entry for an object - which can be a

page, a record, and so on, depending on the
DBMS.
 It contains the following information:
 the nature of the lock (shared or exclusive), and
a pointer to a queue of lock requests
 the number of transactions currently holding a
lock on the object (this can be more than one if
the object is locked in shared mode)
 Implementing Lock and Unlock Requests

 According to the Strict 2PL protocol, before a

transaction T reads or writes a database object O, it
must obtain a shared or exclusive lock on O and
must hold on to the lock until it commits or aborts.
 Implementing Lock and Unlock Requests

 When a transaction needs a lock on an object, it

issues a lock request to the lock manager:

1. If a shared lock is requested, the queue of

requests is empty, and the object is not currently
locked in exclusive mode, the lock manager grants
the lock and updates the lock table entry for the
object (indicating that the object is locked in shared
mode, and incrementing the number of transactions
holding a lock by one).
 Implementing Lock and Unlock Requests

2. If an exclusive lock is requested, and no

transaction currently holds a lock on the object
(which also implies the queue of requests is
empty), the lock manager grants the lock and
updates the lock table entry.

3. Otherwise, the requested lock cannot be

immediately granted, and the lock request is added
to the queue of lock requests for this object. The
transaction requesting the lock is suspended.
 Implementing Lock and Unlock Requests
 When a transaction aborts or commits, it releases all
its locks.
 When a lock on an object is released, the lock
manager updates the lock table entry for the object
and examines the lock request at the head of the
queue for this object.
 If this request can now be granted, the transaction
that made the request is woken up and given the
lock.
 Indeed, if there are several requests for a shared lock
on the object at the front of the queue, all of these
requests can now be granted together.
 Implementing Lock and Unlock Requests

 If T1 has a shared lock on O, and T2 requests an

exclusive lock, T2's request is queued.
 Now, if T3 requests a shared lock, its request
enters the queue behind that of T2, even though
the requested lock is compatible with the lock held
by T1.
 This rule ensures that T2 does not starve, that is,
wait indefinitely while a stream of other transactions
acquire shared locks and thereby prevent T2 from
getting the exclusive lock that it is waiting for.
 Atomicity of Locking and Unlocking

 The implementation of lock and unlock commands

must ensure that these are atomic operations.

 To ensure atomicity of these operations when

several instances of the lock manager code can
execute concurrently, access to the lock table has
to be guarded by an operating system
synchronization mechanism such as a semaphore.
 Additional Issues:
Lock Upgrades, Convoys, Latches

 The DBMS maintains a transaction table, which

contains (among other things) a list of the locks
currently held by a transaction.
 This list can be checked before requesting a lock, to
ensure that the same transaction does not request
the same lock twice.
 However, a transaction may need to acquire an
exclusive lock on an object for which it already
holds a shared lock.
 Additional Issues:
Lock Upgrades, Convoys, Latches

 Such a lock upgrade request is handled specially

by granting the write lock immediately if no other
transaction holds a shared lock on the object and
inserting the request at the front of the queue
otherwise.
 The rationale for favoring the transaction thus is
that it already holds a shared lock on the object and
queuing it behind another transaction that wants an
exclusive lock on the same object causes both
transactions to wait for each other and therefore be
blocked forever
 Additional Issues:
Lock Upgrades, Convoys, Latches

 This interleaving interacts with the operating

system's scheduling of processes' access to the
CPU and can lead to a situation called a convoy,
where most of the CPU cycles are spent on
process switching.
 The problem is that a transaction T holding a
heavily used lock may be suspended by the
operating system.
 Additional Issues:
Lock Upgrades, Convoys, Latches

 Until T is resumed, every other transaction that

needs this lock is queued.
 Such queues, called convoys, can quickly become
very long; a convoy, once formed, tends to be
stable.
 Convoys are one of the drawbacks of building a
DBMS on top of a general-purpose operating
system with preemptive scheduling.
 Additional Issues:
Lock Upgrades, Convoys, Latches

 In addition to locks, which are held over a long

duration, a DBMS also supports short duration
latches.
 Setting a latch before reading or writing a page
ensures that the physical read or write operation is
atomic; otherwise, two read/write operations might
conflict
 Latches are unset immediately after the physical
read or write operation is completed.
End of Chapter 6
(part-1)