Transaction Management

Pearson Education © 2014

Serial Schedule
• Transactions run sequentially
• No interleaving of transaction operations
• Multiple serial schedules are possible for a set of
transactions
• E.g., T1, T2 T3; OR T1, T3, T2; OR T2, T1, T3, ….
• This limits degree of concurrency
• Decreases system throughput since many transactions
must wait for others even when they share no data
(records) in common
• This is true even when only 1 processor since lots of
waiting on disk I/O; particularly true in multi-
processors architectures

Pearson Education © 2014 2

Nonserial Schedule
• Schedule where operations from set of concurrent
transactions are interleaved.
• Objective of serializability is to find non-serial
schedules that allow transactions to execute
concurrently without interfering with one another.
• In other words, want to find non-serial schedules
that are equivalent to some serial schedule. Such a
non-serial schedule is called serializable

Pearson Education © 2014 3

Serializability Recap
Non-Serial Schedule
An schedule for concurrent transactions whose
operations are interleaved
Serializable Schedule
A non-serial (i.e., concurrent/interleaved) schedule
whose output matches that of some serial schedule

Pearson Education © 2014 4

Serializability
• In serializability, ordering of read/writes is
important:
(a) If two transactions only read a data item, they do not
conflict and order is not important.
(b) If two transactions either read or write separate data
items, they do not conflict and order is not
important.
(c) If one transaction writes a data item and another
reads or writes same data item, order of execution is
important.

Pearson Education © 2014 5

Conflicts
• Two actions are said to conflict if:
• Actions belong to different transactions
• Actions access the same object
• At least one of the actions is a write
• Two schedules S1 and S2 are said to be conflict
equivalent if
• Both S1 and S2 contain the same set of transactions
• Both schedules have the same set of conflicting actions.

Pearson Education © 2014 6

Conflicts
• A schedule is conflict serializable if:
• It is conflict equivalent to one or more serial schedules
• Also expressed as:
• If and only if its precedence graph (considering only committed
transactions) is acyclic

Pearson Education © 2014 7

Example of Conflict Serializability
Consider the following schedules (a), (b), and (c) for transactions
T7 and T8. Both transactions read and write balx and baly. Since
(a) and (b) are equivalent to serial schedule (c), they are conflict
serializable.

Non-serial, equiv (c) Non-serial, equiv (c) Serial

Pearson Education © 2014 8
Precedence Graph
• Create (order matters; do this for specific schedule
of interleaved actions):
• node for each transaction;
• a directed edge Ti ® Tj, if
• Tj reads the value of an item written by TI; OR
• Tj writes a value into an item after it has been read by Ti; OR
• Tj writes a value into an item after it has been written by Ti;
• If an edge exists from Ti to Tj, then Ti must be
scheduled prior to Tj
• Thus, if precedence graph contains cycle schedule is not
conflict serializable.

Pearson Education © 2014 9

Example - Non-conflict serializable schedule

• T9 is transferring £100 from one account with

balance balx to another account with balance baly.
• T10 is increasing balance of these two accounts by
10%.
• Precedence graph has a cycle and so is not
serializable.

Pearson Education © 2014 10

Example - Non-conflict serializable schedule

• T10 reads balx, T9 writes balx (arrow from T9 to T10); label x

• T9 reads baly, T10 writes baly (arrow from T10 to T9); label y
• Many more arrows possible in this example
• Once we have a cycle, we know not conflict serializable 11
Pearson Education © 2014
Recoverability
• Serializability identifies schedules that maintain
database consistency, assuming no transaction
fails.
• If transaction fails, atomicity requires effects of
transaction to be undone.
• Durability states that once transaction commits, its
changes cannot be undone (without running
another, compensating, transaction).

Pearson Education © 2014 12

Recoverable Schedule

A schedule where, for each pair of transactions Ti

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

i.e, If one transaction reads a data item written by

the other , the transaction doing the writing must
commit before the read
Thus, all data items read are from committed, not
“in process” transactions

Pearson Education © 2014 13

Concurrency Control Techniques
• Two basic concurrency control techniques:
• Locking,
• Timestamping.
• Both are conservative approaches: delay
transactions in case they conflict with other
transactions.
• Conflict avoidance
• Look for possible conflicts and set up schedules that
prevent the conflicts from happening

Pearson Education © 2014 14

Concurrency Control Techniques
• On the other hand, optimistic methods assume
conflict is rare and only check for conflicts at
commit.
• Conflict resolution
• Detect whether or not actual conflicts have occurred
• Rollback (undo) affected transactions

Pearson Education © 2014 15

Conflict Avoidance: Locking
Transaction uses locks to deny access to other
transactions and so prevent incorrect updates.

• Most widely used approach to ensure serializability.

• Generally, a transaction must claim a shared (read)
or exclusive (write) lock on a data item before read
or write.
• Lock prevents another transaction from modifying
item or even reading it, in the case of a write lock.

Pearson Education © 2014 16

Locking - Basic Rules
• Shared lock on item (read lock)
• Reads cannot conflict
• All transactions can read but not update item.
• Exclusive lock on item
• Writes could conflict; prevent that
• Only 1 transaction can read and/or write item.

Pearson Education © 2014 17

Reexamine Conflicting Transactions
• Even locking won’t guarantee serializability

T9 transfers 100 from y

to x

T10 adds 10% to x and y

Example - Incorrect Locking Schedule
• If at start, balx = 100, baly = 400
• Serial schedule T9 then T10
• Transfer 100, then add 10%
• balx = 200, baly = 300; add 10% 100
• balx = 220, baly = 330
• Serial schedule T10 then T9
• Add 10%, then transfer 100
• balx = 110, baly=440; transfer 100
• balx = 210, baly = 340
These are only 2 possible serial results
To be serializable, any non-serial schedule must produce one
of these sets of values

Pearson Education © 2014 19

Reexamine Conflicting Transactions
• Even locking won’t guarantee serializability

write lock x

unlock x
write lock x, y

unlock x, y
write lock y

unlock y
Result:

• balx = 200 by T9
• balx = 220 T10
• baly = 440 T10
• baly = 340 T10
• The end result: balx == 220, baly == 340 does not
match either of the serial schedules
• Even adding exclusive locks around each read/write doesn’t
guarantee serializability
Example - Incorrect Locking Schedule
• Problem is that transactions release locks too soon,
resulting in loss of total isolation and atomicity.
• To guarantee serializability, need an additional
protocol concerning the positioning of lock and
unlock operations in every transaction.

Pearson Education © 2014 22

Two-Phase Locking (2PL)
Transaction follows 2PL protocol if all locking
operations precede first unlock operation in the
transaction.

• Two phases for transaction:

• Growing phase - acquires all locks but cannot release
any locks.
• Shrinking phase - releases locks but cannot acquire
any new locks.

Pearson Education © 2014 23

Preventing Lost Update Problem using 2PL

T2 requests a write (exclusive) lock on balx; receives it

T1 requests a write (exclusive) lock on balx; must wait
T2 releases lock on balx
T1 receives lock on balx and proceeds
Pearson Education © 2014 24
Preventing Uncommitted Dependency Problem
using 2PL

T4 requests a write (exclusive) lock on balx; receives it

T3 requests a write (exclusive) lock on balx; must wait
T4 fails in its update of balx, rolls value back to 100
T4 releases its lock after rollback
T1 receives lock on bal x and
Pearson
proceeds
Education © 2014 25
Preventing Inconsistent Analysis Problem using 2PL

T5 requests write locks on balx and balz before each read

T4 requests shared locks on balx, baly, balz before each read
T5 and T4 only release locks at end of transaction (with commit)
Pearson Education © 2014 26
Strict Two-Phase Locking
• If every transaction in a schedule follows 2PL,
schedule is serializable.
• However, problems can occur with interpretation
of when locks can be released.
• If release locks after writes (but before commit at end of
transaction), can get non-serializable schedules caused
by with cascading rollbacks
• Strict Two Phase Locking:
• 2PL with additional requirement that all locks are removed at
end of transaction
• Guarantees serializability even with cascading rollback
• Decreases concurrency (throughput)

Pearson Education © 2014 27

Concurrency Control with Index Structures
• Could treat each page of index as a data item and
apply 2PL.
• However, as indexes will be frequently accessed,
particularly higher levels, this may lead to high lock
contention.
• Two points about index traversal:
• Search path starts from root and moves down to leaf
nodes but search never moves back up tree. Thus, once a
lower-level node has been accessed, higher-level nodes
in that path will not be used again.
• When new index value (key and pointer) is being inserted
into a leaf node, then if node is not full, insertion will not
cause changes to higher-level nodes.

Pearson Education © 2014 28

Concurrency Control with Index Structures
• Only have to exclusively lock leaf node in such a
case, and only exclusively lock higher-level nodes if
node is full and has to be split.
• Thus, can derive following locking strategy:
• For searches, obtain shared locks on nodes starting at root
and proceeding downwards along required path. Release lock
on node once lock has been obtained on the child node.
• For insertions, conservative approach (conflict avoidance)
would be to obtain exclusive locks on all nodes as we descend
tree to the leaf node to be modified.
• For more optimistic approach (conflict resolution), obtain
shared locks on all nodes as we descend to leaf node to be
modified, where obtain exclusive lock. If leaf node has to split,
upgrade shared lock on parent to exclusive lock. If this node
also has to split, continue to upgrade locks at next higher
level.
Pearson Education © 2014 29
Deadlock
An impasse that may result when two (or more)
transactions are each waiting for locks held by the
other to be released.

Pearson Education © 2014 30

Deadlock
• Three general techniques for handling deadlock:
• Deadlock prevention.
• Timeouts.
• Deadlock detection and recovery.

Pearson Education © 2014 31

Deadlock Prevention
• DBMS looks ahead to see if transaction would cause
deadlock and never allows deadlock to occur.
• Could order transactions using transaction
timestamps:
• Wait-Die - older transaction waits for younger one; older
transaction is aborted if necessary. Allows recent jobs
(short ones) to complete
• Wound-Wait - younger transaction waits for an older
one. If older transaction requests lock held by younger
one, younger one is aborted (wounded). Allows long jobs
to complete.

Pearson Education © 2014 32

Timeouts

• Transaction that requests lock will only wait for a

system-defined period of time.
• If lock has not been granted within this period, lock
request times out.
• In this case, DBMS assumes transaction may be
deadlocked, even though it may not be, and it
aborts and automatically restarts the transaction.

Pearson Education © 2014 33

Deadlock Detection and Recovery
• DBMS allows deadlock to occur but recognizes it
and breaks it.
• Usually handled by construction of wait-for graph
(WFG) showing transaction dependencies:
• Create a node for each transaction.
• Create edge Ti -> Tj, if Ti waiting to lock item locked by Tj.
• Deadlock exists if and only if WFG contains cycle.
• WFG is created at regular intervals.

Pearson Education © 2014 34

Example - Wait-For-Graph (WFG)

Pearson Education © 2014 35

Recovery from Deadlock Detection

• Several issues:
• choice of deadlock victim;
• how far to roll a transaction back;
• avoiding starvation
• Where one transaction (say the longest one) is not explicitly
prevented from progressing, but actually never does progress
• Wait-Die: long transactions repeatedly aborted to give priority to
shorter transactions
• Wound-Wait: short transactions never started because longer
transactions are always in process

Pearson Education © 2014 36

Timestamping
• Locks + Strict 2PL Transactions guarantees
serializabilty
• Another approach based on timestamps can also
guarantee serializable schdules (although it may or
may not generate the same serializable schedule as
2PL
• No locks so no deadlock.

Pearson Education © 2014 37

Timestamping
Timestamp
A unique identifier created by DBMS that indicates
relative starting time of a transaction.
• Can be generated by using system clock at time
transaction started, or by incrementing a logical
counter every time a new transaction starts.
• ordered globally so that older transactions,
transactions with smaller timestamps, get priority
in the event of conflict.
• Conflict is resolved by rolling back and restarting
transaction.

Pearson Education © 2014 38

Timestamping
• Add timestamps for data items:
• read-timestamp - timestamp of last transaction to read
item;
• write-timestamp - timestamp of last transaction to write
item.
• Read/write proceeds only if last update on that
data item was carried out by an older transaction.
• Otherwise, transaction requesting read/write is
restarted and given a new timestamp.

Pearson Education © 2014 39

Optimistic Techniques
• Locking and Timestamping techniques focus on
preventing conflicts
• In some systems, conflict is rare and more efficient
to let transactions proceed without delays, so no
guarantee of serializability.
• At commit, check is made to determine whether or
not a conflict has occurred.
• If there is a conflict, transaction must be rolled
back and restarted.
• Potentially allows greater concurrency than
traditional protocols.

Pearson Education © 2014 40

Granularity of Data Items
• Size of data items chosen as unit of protection by
concurrency control protocol.
• Ranging from coarse to fine:
• The entire database.
• A file.
• A page (or area or database spaced).
• A record.
• A field value of a record.

Pearson Education © 2014 41

Granularity of Data Items

• Tradeoff:
• coarser, the lower the degree of concurrency;
• finer, more locking information that is needed to be
stored.
• Best item size depends on the types of
transactions.

Pearson Education © 2014 42

Hierarchy of Granularity

• Could represent granularity of locks in a

hierarchical structure.
• Root node represents entire database, level 1s
represent files, etc.
• When node is locked, all its descendants are also
locked.
• DBMS should check hierarchical path before
granting lock.

Pearson Education © 2014 43

Levels of Locking

Pearson Education © 2014 44

Database Recovery

Process of restoring database to a correct state in

the event of a failure.

• Need for Recovery Control

• Two types of storage: volatile (main memory) and
nonvolatile.
• Volatile storage does not survive system crashes.
• Stable storage represents information that has been
replicated in several nonvolatile storage media with
independent failure modes.

Pearson Education © 2014 45

Types of Failures

• System crashes, resulting in loss of main memory.

• Media failures, resulting in loss of parts of
secondary storage.
• Application software errors.
• Natural physical disasters.
• Carelessness or unintentional destruction of data
or facilities.
• Sabotage.

Pearson Education © 2014 46

Transactions and Recovery
• Transactions represent basic unit of recovery.
• Recovery manager responsible for atomicity and
durability.
• If failure occurs between commit and database
buffers being flushed to secondary storage then,
to ensure durability, recovery manager has to redo
(rollforward) transaction’s updates.

Pearson Education © 2014 47

Transactions and Recovery
• If transaction had not committed at failure time,
recovery manager has to undo (rollback) any
effects of that transaction for atomicity.
• Partial undo - only one transaction has to be
undone.
• Global undo - all transactions have to be undone.

Pearson Education © 2014 48

Recovery Facilities

• DBMS should provide following facilities to assist

with recovery:
• Backup mechanism, which makes periodic backup
copies of database.
• Logging facilities, which keep track of current state
of transactions and database changes.
• Checkpoint facility, which enables updates to
database in progress to be made permanent.
• Recovery manager, which allows DBMS to restore
database to consistent state following a failure.

Pearson Education © 2014 49

Log File

• Contains information about all updates to

database:
• Transaction records.
• Checkpoint records.
• Often used for other purposes (for example,
auditing).

Pearson Education © 2014 50

Log File
• Transaction records contain:
• Transaction identifier.
• Type of log record, (transaction start, insert, update,
delete, abort, commit).
• Identifier of data item affected by database action (insert,
delete, and update operations).
• Before-image of data item.
• After-image of data item.
• Log management information.

Pearson Education © 2014 51

Sample Log File

Pearson Education © 2014 52

Log File

• Log file may be duplexed or triplexed.

• Log file sometimes split into two separate random-
access files.
• Potential bottleneck; critical in determining overall
performance.

Pearson Education © 2014 53

Checkpointing
Checkpoint
Point of synchronization between database and log file.
All buffers are force-written to secondary storage.

• Checkpoint record is created containing identifiers

of all active transactions.
• When failure occurs, redo all transactions that
committed since the checkpoint and undo all
transactions active at time of crash.

Pearson Education © 2014 54

Main Recovery Techniques

• Three main recovery techniques:

• Deferred Update
• Immediate Update
• Shadow Paging

Pearson Education © 2014 55

Deferred Update

• Updates are not written to the database until after

a transaction has reached its commit point.
• If transaction fails before commit, it will not have
modified database and so no undoing of changes
required.
• May be necessary to redo updates of committed
transactions as their effect may not have reached
database.

Pearson Education © 2014 56

Immediate Update

• Updates are applied to database as they occur

(don’t wait for commit).
• As before, to redo updates of committed
transactions following a failure (may not have
reached db).
• May need to undo effects of transactions that had
not committed at time of failure.
• Essential that log records are written before write
to database. Write-ahead log protocol.

Pearson Education © 2014 57

Shadow Paging
• Maintain two page tables during life of a
transaction: current page and shadow page table.
• When transaction starts, two pages are the same.
• Shadow page table is never changed thereafter and
is used to restore database in event of failure.
• During transaction, current page table records all
updates to database.
• When transaction completes, current page table
becomes shadow page table.

Pearson Education © 2014 58