Transaction Management and

Concurrency Control
What is a Transaction?
□ Any action that reads from and/or writes to a
database may consist of
■ Simple SELECT statement to generate a list of
table contents
■ A series of related UPDATE statements to change
the values of attributes in various tables
■ A series of INSERT statements to add rows to one
or more tables
■ A combination of SELECT, UPDATE, and INSERT
statements

Database Systems 6e/ Rob & Coronel Slide 2

What is a Transaction?

□ A logical unit of work that must be either entirely

completed or aborted
□ Successful transaction changes the database from
one consistent state to another
■ One in which all data integrity constraints are
satisfied
□ Most real-world database transactions are formed
by two or more database requests
■ The equivalent of a single SQL statement in an
application program or transaction

Database Systems 6e/ Rob & Coronel Slide 3

Transaction Properties
□ Atomicity
■ Requires that all operations (SQL requests) of a
transaction be completed; if not, then the
transaction is aborted
■ A transaction is treated as a single, indivisible,
logical unit of work
□ Durability
■ Indicates permanence of database’s consistent
state
■ When a transaction is complete, the database
reaches a consistent state. That state can not be
lost even if the system fails
□ Consistency
■ Execution of a transaction in isolation preserves
the consistency of the database.
Database Systems 6e/ Rob & Coronel Slide 4
 Transaction Properties

■ When the transaction completes successfully the

database must be consistent
□ Serializability
■ Ensures that the concurrent execution of several
transactions yields consistent results
■ Multiple, concurrent transactions appear as if
they executed in serial order (one after another)
□ Isolation
■ Data used during execution of a transaction
cannot be used by second transaction until first
one is completed

Database Systems 6e/ Rob & Coronel Slide 5

Transaction State
□ Active - the initial state; the transaction stays in this
state while it is executing
□ Partially committed - after the final statement has
been executed.
□ Failed - after the discovery that normal execution can
no longer proceed.
□ Aborted - after the transaction has been rolled back and
the database restored to its state prior to the start of the
transaction. Two options after it has been aborted:
■ restart the transaction
□ can be done only if no internal logical error
■ kill the transaction
□ Committed - after successful completion.

Database Systems 6e/ Rob & Coronel Slide 6

Transaction State (Cont.)

Database Systems 6e/ Rob & Coronel Slide 7

Transaction Management with SQL
□ ANSI(American National Standards Institute
Structured Query Language) has defined standards
that govern SQL database transactions
□ Transaction support is provided by two SQL
statements: COMMIT and ROLLBACK
□ ANSI standards require that, when a transaction
sequence is initiated by a user or an application
program, it must continue through all succeeding SQL
statements until one of four events occurs

Database Systems 6e/ Rob & Coronel Slide 8

Transaction Management with SQL
1. A COMMIT statement is reached- all changes are
permanently recorded within the database
2. A ROLLBACK is reached – all changes are aborted and
the database is restored to a previous consistent state
3. The end of the program is successfully reached –
equivalent to a COMMIT

Database Systems 6e/ Rob & Coronel Slide 9

 The Transaction Log
□ Keeps track of all transactions that update the
database. It contains:

■ A record for the beginning of transaction

■ For each transaction component (SQL statement)
□ Type of operation being performed (update, delete,
insert)
□ Names of objects affected by the transaction (the
name of the table)
□ “Before” and “after” values for updated fields
□ Pointers to previous and next transaction log entries
for the same transaction
■ The ending (COMMIT) of the transaction

Database Systems 6e/ Rob & Coronel Slide 10

 The Transaction Log

■ Increases processing overhead but the ability to

restore a corrupted database is worth the price

■ If a system failure occurs, the DBMS will examine

the log for all uncommitted or incomplete
transactions and it will restore the database to a
previous state

■ The log it itself a database and to maintain its

integrity many DBMSs will implement it on several
different disks to reduce the risk of system failure

Database Systems 6e/ Rob & Coronel Slide 11

 Concurrency Control
□ The coordination of the simultaneous execution of
transactions in a multiprocessing database is
known as concurrency control

□ The objective of concurrency control is to ensure

the serializability of transactions in a multiuser
database environment

Database Systems 6e/ Rob & Coronel Slide 12

Three Concurrency Problems

■ Important simultaneous execution of

transactions over a shared database can
create several data integrity and
consistency problems
■ The three main problems are:

□ lost updates

□ uncommitted data

□ inconsistent retrievals

Database Systems 6e/ Rob & Coronel Slide 13

Uncommited Data Problem

□ Uncommitted data occurs when two transactions

execute concurrently and the first is rolled back
after the second has already accessed the
uncommitted data

■ This violates the isolation property of

transactions

Database Systems 6e/ Rob & Coronel Slide 14

Inconsistent Retrieval Problem

□ Occur when a transaction calculates some

aggregate functions over a set of data while
transactions are updating the data

■ Some data may be read after they are changed

and some before they are changed yielding
inconsistent results

Database Systems 6e/ Rob & Coronel Slide 15

Lock Granularity
□ Indicates the level of lock use
□ Locking can take place at the following levels:
■ Database-level lock
□ Entire database is locked
■ Table-level lock
□ Entire table is locked
■ Page-level lock
□ Entire diskpage is locked
■ Row-level lock
□ Allows concurrent transactions to access different rows
of the same table, even if the rows are located on the
same page
■ 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
Database Systems 6e/ Rob & Coronel Slide 16
A Database-Level Locking Sequence

□ Good for batch processing but unsuitable for online multi-user

DBMSs
□ T1 and T2 can not access the same database concurrently even if
they use different tables

Database Systems 6e/ Rob & Coronel Slide 17

Table-Level Lock

□ T1 and T2 can access the same database concurrently as long as they

use different tables
□ Can cause bottlenecks when many transactions are trying to access the
same table (even if the transactions want to access different parts of the
table and would not interfere with each other)
□ Not suitable for multi-user DBMSs
Database Systems 6e/ Rob & Coronel Slide 18
Page-Level Lock

□ An entire disk page is locked (a table can span several pages and
each page can contain several rows of one or more tables)
□ Most frequently used multi-user DBMS locking method

Database Systems 6e/ Rob & Coronel Slide 19

Row-Level Lock

□ Concurrent transactions can access different rows of the same

table even if the rows are located on the same page
□ Improves data availability but with high overhead (each row has a
lock that must be read and written to)

Database Systems 6e/ Rob & Coronel Slide 20

Field-Level Lock
□ Allows concurrent transactions to
access the same row as long as they
require the use of different fields with
that row
□ Most flexible lock buy requires an
extremely high level of overhead

Database Systems 6e/ Rob & Coronel Slide 21

Binary Locks
□ Has only two states: locked (1) or unlocked (0)
□ Eliminates “Lost Update” problem – the lock is not released until
the write statement is completed
■ Can not use PROD_QOH until it has been properly updated
□ Considered too restrictive to yield optimal concurrency conditions as it
locks even for two READs when no update is being done

Database Systems 6e/ Rob & Coronel Slide 22

Shared/Exclusive Locks
□ Exclusive lock
■ Access is specifically reserved for the transaction that locked the
object
■ Must be used when the potential for conflict exists – when a
transaction wants to update a data item and no locks are currently
held on that data item by another transaction
■ Granted if and only if no other locks are held on the data item
□ Shared lock
■ Concurrent transactions are granted Read access on the basis of a
common lock
■ Issued when a transaction wants to read data and no exclusive lock
is held on that data item
□ Multiple transactions can each have a shared lock on the same data
item if they are all just reading it
□ Mutual Exclusive Rule
■ Only one transaction at a time can own an exclusive lock in the same
object

Database Systems 6e/ Rob & Coronel Slide 23

Shared/Exclusive Locks
□ Increased overhead
■ The type of lock held must be known before a lock can be
granted
■ Three lock operations exist:
□ READ_LOCK to check the type of lock
□ WRITE_LOCK to issue the lock
□ UNLOCK to release the lock
■ A lock can be upgraded from share to exclusive and
downgraded from exclusive to share
□ Two possible major problems may occur
■ The resulting transaction schedule may not be serializable
■ The schedule may create deadlocks

Database Systems 6e/ Rob & Coronel Slide 24

Two-Phase Locking to Ensure Serializability
□ Defines how transactions acquire and relinquish
locks
□ Guarantees serializability, but it does not prevent
deadlocks
■ Growing phase, in which a transaction acquires
all the required locks without unlocking any
data
■ Shrinking phase, in which a transaction
releases all locks and cannot obtain any new
lock

Database Systems 6e/ Rob & Coronel Slide 25

Two-Phase Locking to Ensure Serializability
□ Governed by the following rules:

■ Two transactions cannot have conflicting locks

■ No unlock operation can precede a lock operation

in the same transaction

■ No data are affected until all locks are

obtained—that is, until the transaction is in its
locked point

Database Systems 6e/ Rob & Coronel Slide 26

Two-Phase Locking Protocol

Database Systems 6e/ Rob & Coronel Slide 27

Deadlocks
□ Condition that occurs when two transactions wait for
each other to unlock data
■ T1 needs data items X and Y; T needs Y and X
■ Each gets the its first piece of data but then waits to
get the second (which the other transaction is already
holding) – deadly embrace
□ Possible only if one of the transactions wants to
obtain an exclusive lock on a data item
■ No deadlock condition can exist among shared locks
□ Control through
■ Prevention
■ Detection
■ Avoidance

Database Systems 6e/ Rob & Coronel Slide 28

Deadlock Prevention
□ The deadlock prevention approach does not allow any
transaction to acquire locks that will lead to deadlocks.
The convention is that when more than one transactions
request for locking the same data item, only one of them
is granted the lock.
□ One of the most popular deadlock prevention methods is
pre-acquisition of all the locks. In this method, a
transaction acquires all the locks before starting to
execute and retains the locks for the entire duration of
transaction. If another transaction needs any of the
already acquired locks, it has to wait until all the locks it
needs are available. Using this approach, the system is
prevented from being deadlocked since none of the
waiting transactions are holding any lock.

Database Systems 6e/ Rob & Coronel Slide 29

Deadlock Avoidance
□ The deadlock avoidance approach handles deadlocks
before they occur. It analyzes the transactions and the
locks to determine whether or not waiting leads to a
deadlock.
□ The method can be briefly stated as follows. Transactions
start executing and request data items that they need to
lock. The lock manager checks whether the lock is
available. If it is available, the lock manager allocates the
data item and the transaction acquires the lock. However,
if the item is locked by some other transaction in
incompatible mode, the lock manager runs an algorithm
to test whether keeping the transaction in waiting state
will cause a deadlock or not. Accordingly, the algorithm
decides whether the transaction can wait or one of the
transactions should be aborted.
Database Systems 6e/ Rob & Coronel Slide 30
Deadlock Detection and Removal
□ The deadlock detection and removal approach runs a deadlock detection
algorithm periodically and removes deadlock in case there is one. It does not
check for deadlock when a transaction places a request for a lock. When a
transaction requests a lock, the lock manager checks whether it is available. If
it is available, the transaction is allowed to lock the data item; otherwise the
transaction is allowed to wait.
□ Since there are no precautions while granting lock requests, some of the
transactions may be deadlocked. To detect deadlocks, the lock manager
periodically checks if the wait-forgraph has cycles. If the system is deadlocked,
the lock manager chooses a victim transaction from each cycle. The victim is
aborted and rolled back; and then restarted later. Some of the methods used
for victim selection are −
■ Choose the youngest transaction.
■ Choose the transaction with fewest data items.
■ Choose the transaction that has performed least number of updates.
■ Choose the transaction having least restart overhead.
■ Choose the transaction which is common to two or more cycles.
□ This approach is primarily suited for systems having transactions low and
where fast response to lock requests is needed.
Database Systems 6e/ Rob & Coronel Slide 31