Transactional systems

COURSE 4: Databases
Transactional systems

Databases C4: Transactional systems

Transaction
• Set of operations on the database, set of statements:
• insert, update, delete

• Delimited by statements or function calls of type:

• begin transaction
• end transaction

• All operations are finalized with success or none is saved in the db.

• A transactional system must

• manage concurrent transactions.
• ensure consistent data in case of failure.

Databases C4: Transactional systems

Transaction
Statement 1
Statement 2
commit -- end transaction 1

Statement 3
Statement 4
Statement 5
commit -- end transaction 2

Databases C4: Transactional systems

Transaction properties
ACID

Databases C4: Transactional systems

 ATOMICITY CONSISTENCY ISOLATION DURABILITY

• all changes or none

• collection of steps → single indivisible unit.

• If one operation fails all changes to the database must be undone

• Failures in transaction, example: statement error, violating unique constraint.
• System failures, OS crashed.

Databases C4: Transactional systems

 ATOMICITY CONSISTENCY ISOLATION DURABILITY

• If a transaction is run starting from a database in a consistent state,

the database must be consistent at the end of the transaction.

• Database constraints
• PRIMARY KEY key constraint, UNIQUE, NOT NULL, FOREIGN KEY referential integrity,
CHECK

• Business constrains

Databases C4: Transactional systems

 ATOMICITY CONSISTENCY ISOLATION DURABILITY

• The database may at some point be in an inconsistent state.

• Inconsistencies are not visible in a database system (ensured by

atomicity).

• The old values of any data on which a transaction performs is written

to a log file used by a
→ recovery system
Databases C4: Transactional systems
 ATOMICITY CONSISTENCY ISOLATION DURABILITY

• The database system must ensure that transactions run without

interference.
• For any pair of transactions 𝑇𝑖 , 𝑇𝑗 ,
first statement of transaction 𝑇𝑖 is executed after 𝑇𝑗 finished or
first statement of transaction 𝑇𝑗 is executed after 𝑇𝑖 finished.

Databases C4: Transactional systems

 ATOMICITY CONSISTENCY ISOLATION DURABILITY

• After a transaction completes successfully, the changes it has made to

the database persist, even if there are system failures.

• Information about the updates performed by the transaction is

written to disk and used to reconstruct the database after failure.
→ recovery system

• Please answer www.menti.com 13 52 85 Q1, Q2, Q3, Q4

Databases C4: Transactional systems
Transaction states

Databases C4: Transactional systems

 partially
committed
committed
Initial state
→ LOG file
→ write old and
new value

active

failed aborted

Databases C4: Transactional systems

 partially
committed
committed
Initial state
→ LOG file
→ write old and
new value
RECOVERY SYSTEM
active terminated
INITIAL CONSISTENT STATE FAILURE FINAL CONSISTENT STATE

failed aborted

Databases C4: Transactional systems

 partially
committed
committed

Final statement
executed

active

failed aborted

Databases C4: Transactional systems

 partially
committed
committed

Final statement
executed
Log → hardware failure →
→ System restart
→ recover updates  Log
active DURABILITY

failed aborted

Databases C4: Transactional systems

 partially
committed
committed

Successful
completion

active

failed aborted

Databases C4: Transactional systems

 partially
committed
committed

active

Normal execution
cannot proceed

failed aborted

Databases C4: Transactional systems

 partially
committed
committed

active
failure → recover initial state  LOG
CONSISTENCY
Normal execution
cannot proceed

failed aborted

Databases C4: Transactional systems

 partially
committed
committed

active

Rollbacked, initial
stat resolved

failed aborted

Databases C4: Transactional systems

Concurrent transactions

Databases C4: Transactional systems

Concurrent transactions
• Reduce response time: time for a transaction to be completed.

• Improved workload/resource utilization.

• ISOLATION may be violated → as a result database may be found in

an inconsistent state
→ Concurrency control

Databases C4: Transactional systems

Concurrent transactions - conflicts
• Serial execution preserves consistency, assuming that transactions preserve
consistency.
first statement of transaction 𝑇𝑖 is executed after 𝑇𝑗 finished or
first statement of transaction 𝑇𝑗 is executed after 𝑇𝑖 finished
single threaded transactions

• Instructions I of 𝑇𝑖 and J of 𝑇𝑗 conflict  there exists a data accessed by both I

and J, and at least one of I an J write data.
1. I = read(data) J = read(data) I and J don’t conflict.
2. l = read(data) J = write(data) conflict
3. I = write(data) J = read(data) conflict
4. I = write(data) J = write(data) conflict

Databases C4: Transactional systems

Concurrent transactions -- Schedules
• Schedules: sequences of instructions that specify the chronological
order in which instructions of concurrent transactions are executed
• A schedule for a set of transactions must consist of all instructions of those
transactions.
• A schedule 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
• By default transaction assumed to execute commit instruction as its last step.
• A transaction that fails to successfully complete its execution will have an
abort instruction as the last statement.

Databases C4: Transactional systems

Schedules example S1
T1 T2
read (A)
• Serial execution. A := A - 50
write (A)
• No conflicts. read (B)
B := B + 50
• DB in consistent state write (B)
• A.new + B.new = A.old + B.old commit
read (A)
temp := A * 0.1
A := A - temp
write (A)
read (B)
B := B + temp
write (B)
commit

Databases C4: Transactional systems

Schedules example S2
T1 T2
read (A)
• Not a serial execution. A := A - 50
write (A)
• Equivalent to Schedule S1. read (A)
temp := A * 0.1
• DB in consistent state A := A - temp
• A.new + B.new = A.old + B.old write (A)
read (B)
B := B + 50
write (B)
commit

read (B)
B := B + temp
write (B)
commit

Databases C4: Transactional systems

Concurrent transactions
• A (possibly concurrent) schedule is serializable if it is equivalent to a
serial schedule. Different forms of schedule equivalence:
1. Conflict serializability

2. View serializability

Databases C4: Transactional systems

Concurrent transactions
• A (possibly concurrent) schedule is serializable if it is equivalent to a
serial schedule. Different forms of schedule equivalence:
1. 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.

2. View serializability

Databases C4: Transactional systems

Schedules example S2
T1 T2
read (A)
• Not a serial execution. A := A - 50
write (A)
• Equivalent to Schedule S1. read (A)
temp := A * 0.1
• DB in consistent state A := A - temp
• A.new + B.new = A.old + B.old write (A)
read (B)
no conflict, no data B := B + 50
item is updated by write (B)
both blocks, by commit
swapping the two
blocks we obtain S1 read (B)
B := B + temp
write (B)
commit

Databases C4: Transactional systems

Schedules example S3
T1 T2
read (A)
• Not a serial execution. A := A - 50
read (A)
• Not equivalent to Schedule S1. temp := A * 0.1
A := A - temp
• DB in inconsistent state write (A)
• A.new + B.new != A.old + B.old write (A)
read (B)
B := B + 50
conflict, A is updated write (B)
by both blocks commit
read (B)
B := B + temp
write (B)
commit

Databases C4: Transactional systems

Concurrent transactions
1. Conflict serializability
2. View serializability
Let S and S’ be 2 schedules with the same set of transactions. S and S’ are view equivalent
if the following 3 conditions are met, for each data item Q:
• If in schedule S, transaction Ti reads the initial value of Q, then in
schedule S’ also transaction Ti must read the initial value of Q.
• If in schedule S transaction Ti executes read(Q), and that value was produced by
transaction Tj (if any), then in schedule S’ also transaction Ti must read the value of Q
that was produced by the same write(Q) operation of transaction Tj .
• The transaction (if any) that performs the final write(Q) operation in schedule S must
also perform the final write(Q) operation in schedule S’.
View equivalence is also based purely on reads and writes alone.

Databases C4: Transactional systems

Concurrent transactions
• Test serializability:
1. Conflict serializability

➢ Consider some schedule of a set of transactions T1, T2, ..., Tn

➢ Precedence graph — a direct graph where the vertices are the transactions (names).

➢ We draw an arc from Ti to Tj if the 2 transaction conflict, and Ti accessed the data item on which
the conflict arose earlier.

➢ We may label the arc by the item that was accessed.

➢ A schedule is CS if and only if its precedence graph is acyclic.

➢ If precedence graph is acyclic, the serializability order can be obtained by a topological sorting of
the graph.

Databases C4: Transactional systems

Concurrent transactions
• Test serializability :
2. View serializability

➢ The problem of checking if a schedule is view serializable falls in the class of NP-complete
problems. Thus, existence of an efficient algorithm is extremely unlikely.

➢ Practical algorithms that just check some sufficient conditions for view serializability can still
be used.

Please answer www.menti.com 13 52 85 Q5

Databases C4: Transactional systems

Isolation levels

Databases C4: Transactional systems

Isolation levels
• Isolation: execute a transaction as if there are no other concurrent
transactions running simultaneously.

• Prevent read or write of incorrect, temporary, aborted data processed by

concurrent transactions

• Isolation levels: trade off between perfect isolation and performance

• response time: time before a transaction completes
• throughput: number of transactions per second

Databases C4: Transactional systems

Level Serializability, perfect isolation
• The final state of the database is equivalent to a state of the database
if the transactions were run sequentially.
• serializable schedule

• Way of obtaining serializability:

• locking
• timestamp validation
• multi-versioning

Databases C4: Transactional systems

 T1 T2
select qte into :nS
Transactions errors from stock
where n_prod = 100
--nS = 13
select qte into :nS
from stock
where n_prod = 100
update stock
set qte = :nS - 1
where n_prod = 100
update stock
set qte = :nS - 1
lost-update anomaly where n_prod = 100
insert into
final stock 12!
orders(n_prod, qte)
values(100, 1)
commit
insert into
orders(n_prod, qte)
Databases C4: Transactional systems values(100, 1)
 T1 T2
select qte into :nS
Transactions errors from stock
where n_prod = 100
--nS = 13
update stock
set qte = :nS - 1
where n_prod = 100
select sum(qte)
into :nO
from orders
dirty-read anomaly where n_prod = 100
number of products
ordered + qte_stock != select qte into :nS
initial stock from stock
1 product missing! where n_prod = 100
Read uncommitted --nO+nS!=init_stock
data
insert into orders(n_prod,
qte) values(100, 1)
commit

Databases C4: Transactional systems

 T1 T2
… select qte into :nS
Transactions errors from stock
where n_prod = 100
--nS = 10

if nS < 15 and nS >= 10

insert into restock(n_prod, qte)
values(100, 5)

update stock
set qte = :nS - 1
where n_prod = 100

insert into orders

non-repeatable read (n_prod, qte)
values(100, 1)
anomaly
only one insert into commit
restock is needed! select qte into :nS
read twice, different from stock
values where n_prod = 100

if nS < 10
insert into restock(n_prod, qte)
values(100, 15)

Databases C4: Transactional systems

Transactions errors

T1 T2
select MAX(qte)
into :max
from orders
where n_prod =
100
phantom-read insert into orders(n_prod,qte)
anomaly values(100, 789455)
AVG > MAX! commit
select AVG(qte)
new lignes inserted into :avarage
from orders
where n_prod =
100
Databases C4: Transactional systems
 T1 T2
select qte into :nS
Transactions errors from stock
where n_prod = 100
--nS = 13
update stock
set qte = :nS - 1
where n_prod = 100
select qte into :nS
from stock
where n_prod = 100
--nS = 12
dirty-write anomaly update stock
final stock 11! In the set qte = :nS - 1
first transaction, the where n_prod = 100
stock returns to 13. --nS = 11
Only one update
should decrease the abort
number of products. insert …
commit

Databases C4: Transactional systems

Isolation levels
• weaker the isolation level → more anomalies may occur
ERROR lost-update dirty-reads non-repeatable phantom
LEVEL reads

READ
UNCOMMITTED
READ
COMMITTED
REPEATABLE
READ

SERIALIZABLE

Databases C4: Transactional systems

Isolation levels

ERROR lost-update dirty-reads non-repeatable phantom

LEVEL reads

REPEATABLE
READ

• read only committed

• between two reads of an item by a transaction, no other transaction is
allowed to update it.
• a transaction may find other data inserted by a committed transaction

Databases C4: Transactional systems

Isolation levels

ERROR lost-update dirty-reads non-repeatable phantom

LEVEL reads

READ
COMMITTED

• read only committed

• does not require repeatable reads. Between two reads of a data item
by the transaction, another transaction may have updated the data
item and committed.
Databases C4: Transactional systems
Isolation levels

ERROR lost-update dirty-reads non-repeatable phantom

LEVEL reads

READ
UNCOMMITTED

• allows uncommitted data to be read

• all the isolation levels prevent writes to a data item that has already been written
by another transaction not yet committed or aborted (rollbacked).

• Please answer www.menti.com 13 52 85 Q6, Q7

Databases C4: Transactional systems

Achieving isolation
• Versioning
• Transactions read from a “snapshot” of the database.

• Locking

• Timestamp

Databases C4: Transactional systems

Locking
• Locks prevent destructive interactions between transactions accessing the same
resource.
• Shared access to read
• Exclusive access to read and write

• Locks (Shared, Shared) compatible.

• Locks (Shared, Exclusive) not compatible.

• A transaction waits until all incompatible locks held by other transactions are released.

• https://oracle-base.com/articles/misc/deadlocks
• https://docs.oracle.com/cd/B19306_01/server.102/b14220/consist.htm
Databases C4: Transactional systems
Snapshot isolation
• Snapshot of the database at the beginning of each transaction.

• The transaction operates only on that snapshot.

• The snapshot consists only of committed values.

• Updates are kept in transaction workspace until commit.

• Implemented with timestamp-versioning

Databases C4: Transactional systems

Consistency levels
To be added, more info in the following video.

Databases C4: Transactional systems

BASE
NoSql consistency model
To be added, more info in the following video.

Databases C4: Transactional systems