Database management systems

Concurrency control

Nguyen Hai Chau

Email: [email protected]
University of Engineering and Technology
Vietnam National University

N. H. Chau (UET, VNU) DBMS: Concurrency control 1 / 26

Interleaved vs parallel processing

N. H. Chau (UET, VNU) DBMS: Concurrency control 2 / 26

Introduction to transaction

Most of the DBMSs are multiuser: Multiple users and programs

access one database simultaneously
Database concurrency is assumed on the time-sharing (or
interleaved) computer systems
Transaction: set of database access operations form a logical
unit of database processing:
begin transaction
operation 1
operation 2
…
end transaction

N. H. Chau (UET, VNU) DBMS: Concurrency control 3 / 26

A simplified database model

A database = a collection of named data items

Each item has a unique name
Basic database access operations:
read_item(X): read a database item named X into a program
X variable
write_item(X): write the value of program variable X into the
database item named X

N. H. Chau (UET, VNU) DBMS: Concurrency control 4 / 26

Examples of transactions

Transactions T1 and T2 access the same data item named X

N. H. Chau (UET, VNU) DBMS: Concurrency control 5 / 26

 Transaction processing

N. H. Chau (UET, VNU) DBMS: Concurrency control 6 / 26

Why concurrency control is needed

Examples of problems may occur in concurrent access to a database

(simultaneously access to the same data items):
The lost update problem
The temporary update (or dirty read) problem
The incorrect summary problem
The unrepeatable read problem
and so on

N. H. Chau (UET, VNU) DBMS: Concurrency control 7 / 26

The lost update problem

N. H. Chau (UET, VNU) DBMS: Concurrency control 8 / 26

The temporary update (dirty read) problem

N. H. Chau (UET, VNU) DBMS: Concurrency control 9 / 26

The incorrect summary problem

N. H. Chau (UET, VNU) DBMS: Concurrency control 10 / 26

The unrepeatable read problem

Unrepeatable read is when a transaction T reads the same item

twice and the item is changed by another transaction T’
between the two reads
Hence, T receives different values for its two reads of the same
item

N. H. Chau (UET, VNU) DBMS: Concurrency control 11 / 26

Transaction operations and
properties

N. H. Chau (UET, VNU) DBMS: Concurrency control 12 / 26

Transaction states and operations

N. H. Chau (UET, VNU) DBMS: Concurrency control 13 / 26

ACID properties of transactions

Atomic: Either all or no operations in a transaction are

performed
Consistency: if a transaction is completely executed from
beginning to end without interference from other transactions, it
should take the database from one consistent state to another
Isolation: the execution of a transaction should not be interfered
with by any other transactions executing concurrently
Durability or permanency: The changes applied to the database
by a committed transaction must persist in the database

N. H. Chau (UET, VNU) DBMS: Concurrency control 14 / 26

ACID properties of transactions

Atomic: responsibility of the transaction recovery subsystem of a

DBMS to ensure
Consistency: responsibility of programmers
A consistent state of the database satisfies the constraints
specified in the schema as well as any other constraints on the
database
A database program must guarantee consistent states of
database, with assumption of no interference of other
transactions
Isolation is enforced by concurrency control subsystem of the
DBMS
Durability is enforced by recovery subsystem of the DBMS

N. H. Chau (UET, VNU) DBMS: Concurrency control 15 / 26

Levels of isolation of transactions

Level 0: A transaction is said to have level 0 (zero) isolation if it

does not overwrite the dirty reads of higher-level transactions
Level 1 isolation has no lost updates
Level 2 isolation has no lost updates and no dirty reads
Level 3 has, in addition to level 2 properties, repeatable reads
Another type of isolation is called snapshot isolation, and several
practical concurrency control methods are based on this

N. H. Chau (UET, VNU) DBMS: Concurrency control 16 / 26

SQL transaction isolation levels

N. H. Chau (UET, VNU) DBMS: Concurrency control 17 / 26

SQL type of violation explained

Dirty read. A transaction T1 may read the update of a

transaction T2, which has not yet committed. If T2 fails and is
aborted, then T1 would have read a value that does not exist
and is incorrect
Nonrepeatable read. A transaction T1 may read a given value
from a table. If another transaction T2 later updates that value
and T1 reads that value again, T1 will see a different value
Phantoms. A transaction T1 may read a set of rows from a
table T based on SQL WHERE clause. A transaction T2 inserts
a new row r that also satisfies the WHERE-clause condition into
T. The record r is called a phantom record because it was not
there when T1 starts but is there when T1 ends

N. H. Chau (UET, VNU) DBMS: Concurrency control 18 / 26

PostgreSQL transaction isolation levels

N. H. Chau (UET, VNU) DBMS: Concurrency control 19 / 26

PostgreSQL type of violation explained

dirty read: A transaction reads data written by a concurrent

uncommitted transaction
nonrepeatable read: A transaction re-reads data it has previously
read and finds that data has been modified by another
transaction (that committed since the initial read)
phantom read: A transaction re-executes a query returning a set
of rows that satisfy a search condition and finds that the set of
rows satisfying the condition has changed due to another
recently-committed transaction
serialization anomaly: The result of successfully committing a
group of transactions is inconsistent with all possible orderings
of running those transactions one at a time

N. H. Chau (UET, VNU) DBMS: Concurrency control 20 / 26

Transactions in PostgreSQL

START TRANSACTION [ transaction_mode [,…]] where

transaction_mode is one of: ISOLATION LEVEL
SERIALIZABLE | REPEATABLE READ | READ COMMITTED
| READ UNCOMMITTED READ WRITE | READ ONLY
BEGIN or BEGIN TRANSACTION can be used
To end a transaction:
COMMIT
ROLLBACK
SET TRANSACTION ISOLATION LEVEL …
SHOW TRANSACTION ISOLATION LEVEL …

N. H. Chau (UET, VNU) DBMS: Concurrency control 21 / 26

SAVEPOINT

SAVEPOINT – define a new savepoint within the current

transaction, syntax:
SAVEPOINT savepoint_name
ROLLBACK [TRANSACTION] TO [SAVEPOINT]
savepoint_name

N. H. Chau (UET, VNU) DBMS: Concurrency control 22 / 26

PostgreSQL read committed isolation level

Read Committed is the default isolation level in PostgreSQL

In this level of isolation:
a SELECT query (without a FOR UPDATE/SHARE clause) sees
only data committed before the query began, it never see
uncommitted data
UPDATE, DELETE, SELECT FOR UPDATE, and SELECT
FOR SHARE commands behave the same as SELECT in terms
of searching for target rows: they will only find target rows that
were committed as of the command start time

N. H. Chau (UET, VNU) DBMS: Concurrency control 23 / 26

PostgreSQL Repeatable Read Isolation Level

The Repeatable Read isolation level only sees data committed

before the transaction began; it never sees either uncommitted
data or changes committed during transaction execution by
other concurrent transactions
UPDATE, DELETE, SELECT FOR UPDATE, and SELECT
FOR SHARE commands behave the same as SELECT in terms
of searching for target rows: they will only find target rows that
were committed as of the transaction start time
Applications using this level must be prepared to retry
transactions due to serialization failures:
ERROR: could not serialize access due to concurrent update

N. H. Chau (UET, VNU) DBMS: Concurrency control 24 / 26

PostgreSQL Serializable Isolation Level

The Serializable isolation level provides the strictest transaction

isolation
This level emulates serial transaction execution for all
committed transactions; as if transactions had been executed
one after another serially rather than concurrently
Applications using this level must be prepared to retry
transactions due to serialization failures

N. H. Chau (UET, VNU) DBMS: Concurrency control 25 / 26

Explicit locking

PostgreSQL provides locking tools for users: explicit locking

Table-level locks
Row-level locks
Advisory locks (application-level lock), similar to semaphores
The use of explicit locking can increase the likelihood of
deadlocks
Deadlocks can occur in table-level or row-level explicit locking
It is the responsibility of applications to avoid deadlocks

N. H. Chau (UET, VNU) DBMS: Concurrency control 26 / 26