TRANSACTIO

NAL
DATABASES
INTRODUCTION TO TRANSACTION
PROCESSING

• A Transaction:
– Logical unit of database processing that includes one or more access
operations (read -retrieval, write - insert or update, delete).
• A transaction (set of operations) may be stand-alone specified in a
high level language like SQL submitted interactively, or may be
embedded within a program.
• Concurrent execution of user programs is essential for good DBMS performance
– Disk access is frequent and slow 
– Want to keep the CPU busy 
• A user’s program may carry out all sorts of operations on the data, but the DBMS is
only concerned about what data is read from/written to the database
TRANSACTIONS CONT.

• Thus a transaction is the DBMS’s abstract view of a user

program: a series of reads/writes of database objects
• Users submit transactions, and can think of each transaction as
executing by itself
– The concurrency is achieved by the DBMS, which interleaves actions of
the various transactions
• Issues:
– Interleaving transactions, and
– Crashes!

3
 CONCURRENT AND PARALLEL
TRANSACTIONS

B B
CPU2
A
CPU1 A
CPU1

time
t1 t2 t1 t2
interleaved processing parallel processing
THE ‘ACID’ PROPERTIES OF
TRANSACTIONS
• Atomicity: Either all actions are carried out, or none are
• Consistency: If each transaction is consistent, and the
database is initially consistent, then it is left consistent
• Isolation: Transactions are isolated, or protected, from
the effects of other scheduled transactions
• Durability: If a transactions complete successfully, then
its effects persist, even if the database crashes

5
ATOMICITY

• A transaction can
– Commit after completing its actions, or
– Abort because of
• Internal DBMS decision: restart
• System crash: power, disk failure, …
• Unexpected situation: unable to access disk, data value, …
• A transaction interrupted in the middle could leave the database inconsistent
• DBMS needs to remove the effects of partial transactions to ensure atomicity: either all a
transaction’s actions are performed or none
• A DBMS ensures atomicity by undoing the actions of partial transactions
• To enable this, the DBMS maintains a record, called a log, of all writes to the database
• The component of a DBMS responsible for this is called the recovery manager

6
CONSISTENCY

• Users are responsible for ensuring transaction consistency

– when run to completion against a consistent database instance, the
transaction leaves the database consistent
• For example, consistency criterion that my inter-account-
transfer transaction does not change the total amount of
money in the accounts! Integrity
Constraints!
• Database consistency is the property that every transaction
sees a consistent database instance. It follows from transaction
atomicity, isolation and transaction consistency

7
ISOLATION

• Guarantee that even though transactions may be interleaved,

the net effect is identical to executing the transactions serially
• For example, if transactions T1 and T2 are executed
concurrently, the net effect is equivalent to executing
– T1 followed by T2, or
– T2 followed by T1
• NOTE: The DBMS provides no guarantee of effective order
of execution

8
DURABILITY

• DBMS uses the log to ensure durability

• If the system crashed 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 is restarted
• Again, this is handled by the recovery manager

9
SCHEDULES
• Schedule – a sequence 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
– 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
SCHEDULES - EXAMPLE

• What is Schedules
– A schedule S of n transactions T1,T2,…Tn is an ordering of the operations of
the transactions subject to the constraint that, for each transaction Ti that
participates in S, the operations of Ti in S must appear in the same order in
which they occur in Ti.
– Example: Sa: r1(A),r2(A),w1(A),w2(A), a1,c2;
T1 T2
Read(A)
Read(A)
Write(A)
Write(A)
Abort T1
Commit T2
SCHEDULES
• A schedule is a list of actions from a set of
transactions
– A well-formed schedule is one where the actions
of a particular transaction T are in the same
order as they appear in T
• For example
– [RT1(a), WT1(a), RT2(b), WT2(b), RT1(c), WT1(c)] is a
well-formed schedule
– [RT1(c), WT1(c), RT2(b), WT2(b), RT1(a), WT1(a)] is not
a well-formed schedule
12
SCHEDULES CONT.

• A complete schedule is one that contains an abort or commit action for

every transaction that occurs in the schedule
• A serial schedule is one where the actions of different transactions are not
interleaved

13
SERIALISABILITY

• A serialisable schedule is a schedule whose effect on any consistent database

instance is identical to that of some complete serial schedule
• NOTE:
– All different results assumed to be acceptable
– It’s more complicated when we have transactions that abort
– We’ll assume that all ‘side-effects’ of a transaction are written to the database
• Being serializable is not the same as being serial
• Being serializable implies that the schedule is a correct schedule.
– It will leave the database in a consistent state.
– The interleaving is appropriate and will result in a state as if the transactions were
serially executed, yet will achieve efficiency due to concurrent execution.

14
SERIALIZABILITY OF
SCHEDULES
• Serial
– A schedule S is serial if, for every transaction T participating in the schedule,
all the operations of T are executed consecutively in the schedule.( No
interleaving occurs in a serial schedule)
• Serializable
– A schedule S of n transactions is serializable if it is equivalent to some serial
schedule of the same n transactions.
• schedules are conflict equivalent if:
– they have the same sets of actions, and
– each pair of conflicting actions is ordered in the same way
• Conflict Serializable
– A schedule is said to be conflict serializable if it is conflict equivalent to a serial
schedule
TRANSACTION STATE
(CONT.)
 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.
ANOMALIES WITH
INTERLEAVED EXECUTION
• Two actions on the same data object conflict if at least one of them is a
write
• We’ll now consider three ways in which a schedule involving two
consistency-preserving transactions can leave a consistent database
inconsistent
• Can lead to insert, update and delete anomalies

18
WR CONFLICTS

• Transaction T2 reads a database object that has been modified by T1 which

Debit €100 Credit €100
has not committed
from a to b

T1: R(a),W(a), R(b),W(b),C

T2: R(a),W(a),R(b),W(b),C
Read a and b
and add 6% “Dirty
interest read”
19
RW CONFLICTS

• Transaction T2 could change the value of an object that has

been read by a transaction T1, while T1 is still in progress

T1: R(a), R(a), W(a), C “Unrepeatable

T2: R(a),W(a),C Read”
Read A (5) Write 5+1=6

T1: R(a), W(a),C

T2: R(a), W(a),C
A is 4 

Read A (5) Write 5-1=4 20

WW CONFLICTS

• Transaction T2 could overwrite the value of an object which has already

been modified by T1, while T1 is still in progress
T1: [W(Britney), W(gmb)] “Set both salaries at £1m”
T2: [W(gmb), W(Britney)] “Set both salaries at $1m”

• But:
“Blind
Write”
T1: W(Britney), W(gmb) gmb gets £1m
T2: W(gmb), W(Britney) Britney gets $1m


21
STRICT TWO-PHASE
LOCKING
• DBMS enforces the following locking protocol:
– Each transaction must obtain an S (shared) lock before
reading, and an X (exclusive) lock before writing
– All locks held by a transaction are released when the
transaction completes
– If a transaction holds an X lock on an object, no other
transaction can get a lock (S or X) on that object
• Strict 2PL allows only serialisable schedules

22
ABORTING

• If a transaction Ti is aborted, then all actions must be undone

– Also, if Tj reads object last written by Ti, then Tj must be aborted!
• Most systems avoid cascading aborts by releasing locks only at
commit time (strict protocols)
– If Ti writes an object, then Tj can only read this after Ti finishes
– Cascading Aborts – a single transaction abort leads to a series of
transaction rollbacks.
• In order to undo changes, the DBMS maintains a log which records
every write

23
THE LOG

• The following facts are recorded in the log

– “Ti writes an object”: store new and old values
– “Ti commits/aborts”: store just a record
• Log records are chained together by transaction id, so it’s easy to undo a
specific transaction
• Log is often duplexed and archived on stable storage (it’s important!)

24
THE END