Chapter 13 Transactions and Concurrency Control

13.1 Introduction
13.2 Transactions
13.3 Nested transactions
13.4 Locks
13.5 Optimistic concurrency control
13.6 Timestamp ordering
13.1 Introduction to transactions

y The goal of transactions

– the objects managed by a server must remain in a consistent state
Š when they are accessed by multiple transactions and
Š in the presence of server crashes

y Recoverable objects
– can be recovered after their server crashes (recovery in Chapter 14)
– objects are stored in permanent storage
y Failure model
– transactions deal with crash failures of processes and omission
failures of communication
y Designed for an asynchronous system
– It is assumed that messages may be delayed
 Banking example
Operations of the Account interface
deposit(amount)
deposit amount in the account Each Account is represented by a remote
withdraw(amount) object whose interface Account provides
withdraw amount from the account operations for making deposits and withdra-
getBalance() → amount wals and for setting and getting the balance.
return the balance of the account
setBalance(amount)
set the balance of the account to amount Figure 13.1
Each Branch of the bank is
Operations of the Branch interface represented by a remote object
create(name) → account whose interface Branch provides
create a new account with a given name operations for creating a new
lookUp(name) → account account, looking one up by
return a reference to the account with the given name name and enquiring about the
branchTotal() → amount total funds at the branch. It
return the total of all the balances at the branch stores a correspondence
between account names and
their remote object references
Atomic operations at server

y first we consider the synchronisation of client operations

without transactions
y when a server uses multiple threads it can perform several
client operations concurrently
y if we allowed deposit and withdraw to run concurrently we
could get inconsistent results
y objects should be designed for safe concurrent access e.g. in
Java use synchronized methods, e.g.
– public synchronized void deposit(int amount) throws RemoteException
y atomic operations are free from interference from
concurrent operations in other threads.
y use any available mutual exclusion mechanism (e.g. mutex)
13.2 Transactions

y Some applications require a sequence of client

requests to a server to be atomic in the sense that:
1. they are free from interference by operations being performed on
behalf of other concurrent clients; and
2. either all of the operations must be completed successfully or they
must have no effect at all in the presence of server crashes.
y Transactions originate from database management
systems
y Transactional file servers were built in the 1980s
y Transactions on distributed objects late 80s and 90s
y Middleware components e.g. CORBA Transaction
service.
A client’s banking transaction

Transaction T:
a.withdraw(100);
b.deposit(100);
c.withdraw(200); Figure 13.2
b.deposit(200);

y This transaction specifies a sequence of related

operations involving bank accounts named A, B and
C and referred to as a, b and c in the program
y the first two operations transfer $100 from A to B
y the second two operations transfer $200 from C to B
Atomicity of transactions

y Transactions are intended to be atomic. There are two

aspects to atomicity
1. All or nothing:
– it either completes successfully, and the effects of all of its operations are
recorded in the objects, or (if it fails or is aborted) it has no effect at all. This
all-or-nothing effect has two further aspects of its own:
– failure atomicity:
Š the effects are atomic even when the server crashes;
– durability:
Š after a transaction has completed successfully, all its effects are saved in
permanent storage.

2. Isolation:
– Each transaction must be performed without interference from other
transactions - there must be no observation by other transactions of a
transaction's intermediate effects
Isolation

y One way to achieve isolation is to perform the

transactions serially – one at a time
y The aim for any server that supports transactions is
to maximize concurrency.
y Concurrency control ensures isolation
y Transactions are allowed to execute concurrently,
having the same effect as a serial execution
– That is, they are serially equivalent or serializable

ACID properties: Atomicity; Consistency; Isolation; Durability

Concurrency control

y We will illustrate the ‘lost update’ and the ‘inconsistent

retrievals’ problems which can occur in the absence of
appropriate concurrency control
– a lost update occurs when two transactions both read the old value of a
variable and use it to calculate a new value
– inconsistent retrievals occur when a retrieval transaction observes values that
are involved in an ongoing updating transaction
y we show how serial equivalent executions of transactions can
avoid these problems
y we assume that the operations deposit, withdraw, getBalance
and setBalance are synchronized operations - that is, their
effect on the account balance is atomic.
 the net effect should be to increase B by 10%
twice - 200, 220, 242.
The lost update problem but it only gets to 220. U’s update is lost.

Transaction T : Transaction U:
balance = b.getBalance(); balance = b.getBalance();
b.setBalance(balance*1.1); b.setBalance(balance*1.1);
a.withdraw(balance/10) c.withdraw(balance/10)
balance = b.getBalance(); $200
balance = b.getBalance(); $200
b.setBalance(balance*1.1); $220
b.setBalance(balance*1.1); $220
a.withdraw(balance/10)
Figure 13.5
$80
c.withdraw(balance/10) $280

y the initial balances of accounts A, B, C are $100, $200. $300

y both transfer transactions increase B’s balance by 10%
 we see an inconsistent
The inconsistent retrievals problem retrieval because V has only
done the withdraw part when
W sums balances of A and B
Transaction V: Transaction W:
a.withdraw(100)
aBranch.branchTotal()
b.deposit(100)

a.withdraw(100); $100
total = a.getBalance() $100
Figure 13.6 total = total+b.getBalance() $300
total = total+c.getBalance()
b.deposit(100) $300

y the initial balances of accounts A and B are both $200

y V transfers $100 from A to B while W calculates branch total (which
should be $400)
Serial equivalence

y if each one of a set of transactions has the correct

effect when done on its own
y then if they are done one at a time in some order the
effect will be correct
y a serially equivalent interleaving is one in which the
combined effect is the same as if the transactions
had been done one at a time in some order
y the same effect means
– the read operations return the same values
– the instance variables of the objects have the same values at the end
A serially equivalent interleaving of T and U
(lost updates cured) their access to B is serial, the other part can overlap

Transaction T: Transaction U:
balance = b.getBalance() balance = b.getBalance()
b.setBalance(balance*1.1) b.setBalance(balance*1.1)
a.withdraw(balance/10) c.withdraw(balance/10)

balance = b.getBalance() $200

b.setBalance(balance*1.1) $220
balance = b.getBalance() $220
Figure 13.7
b.setBalance(balance*1.1) $242
a.withdraw(balance/10) $80
c.withdraw(balance/10) $278

y if one of T and U runs before the other, they can’t get a lost update,
y the same is true if they are run in a serially equivalent ordering
A serially equivalent interleaving of V and W
(inconsistent retrievals cured) we could overlap the 1st line of W with the 2nd line of V

Transaction V: Transaction W:
a.withdraw(100);
aBranch.branchTotal()
b.deposit(100)

a.withdraw(100); $100
b.deposit(100) $300
total = a.getBalance() $100
total = total+b.getBalance() $400
Figure 13.8
total = total+c.getBalance()
...

y if W is run before or after V, the problem will not occur

y therefore it will not occur in a serially equivalent ordering of V and W
y the illustration is serial, but it need not be
Read and write operation conflict rules

Operations of different Conflict Reason Figure 13.9

transactions
read read No Because the effect of a pair of read operations
does not depend on the order in which they are
executed
read write Yes Because the effect of a read and a write operation
depends on the order of their execution
write write Yes Because the effect of a pair of write operations
depends on the order of their execution

y Conflicting operations
y a pair of operations conflicts if their combined effect depends
on the order in which they were executed
– e.g. read and write (whose effects are the result returned by read and the
value set by write)
Serial equivalence Which of their operations conflict?
defined in terms of conflicting operations

y For two transactions to be serially equivalent, it is

necessary and sufficient that all pairs of conflicting
operations of the two transactions be executed in
the same order at all of the objects they both access
y Consider
– T: x = read(i); write(i, 10); write(j, 20); T and U access i and j
– U: y = read(j); write(j, 30); z = read (i);
– serial equivalence requires that either
Š T accesses i before U and T accesses j before U. or
Š U accesses i before T and U accesses j before T.

y Serial equivalence is used as a criterion for

designing concurrency control schemes
A non-serially equivalent interleaving of operations of
transactions T and U

Transaction T: Transaction U:

x = read(i)
write(i, 10) Figure 13.10
y = read(j)
write(j, 30)

write(j, 20)
z = read (i)

y Each transaction’s access to i and j is serialised w.r.t one

another, but
y T makes all accesses to i before U does
y U makes all accesses to j before T does
y therefore this interleaving is not serially equivalent
Recoverability from aborts

y if a transaction aborts, the server must make sure that other

concurrent transactions do not see any of its effects
y we study two problems:
y ‘dirty reads’
– an interaction between a read operation in one transaction and an earlier write
operation on the same object (by a transaction that then aborts)
– a transaction that committed with a ‘dirty read’ is not recoverable
y ‘premature writes’
– interactions between write operations on the same object by different
transactions, one of which aborts
y (getBalance is a read operation and setBalance a write
operation)
A dirty read when transaction T aborts
Transaction T: Transaction U:
a.getBalance() a.getBalance()
a.setBalance(balance + 10) a.setBalance(balance + 20)

balance = a.getBalance() $100 yU reads A’s balance (which was set

a.setBalance(balance + 10) $110 by T) and then commits
balance = a.getBalance() $110
Figure 13.11
a.setBalance(balance + 20) $130
T subsequently aborts. commit transaction
abort transaction

U has performed a dirty read These executions are serially equivalent

y U has committed, so it cannot be undone

Recoverability of transactions

y If a transaction (like U) commits after seeing the effects of a

transaction that subsequently aborted, it is not recoverable

For recoverability:
A commit is delayed until after the commitment of any other
transaction whose state has been observed

y e.g. U waits until T commits or aborts

y if T aborts then U must also abort
 For recoverability - delay commits
Cascading aborts

y Suppose that U delays committing until after T aborts.

– then, U must abort as well.
– if any other transactions have seen the effects due to U, they too must
be aborted.
– the aborting of these latter transactions may cause still further
transactions to be aborted.
y Such situations are called cascading aborts.
To avoid cascading aborts
transactions are only allowed to read objects written by committed transactions.
to ensure this, any read operation must be delayed until other transactions that
applied a write operation to the same object have committed or aborted.

e.g. U waits to perform getBalance until T commits or aborts

Avoidance of cascading aborts is a stronger condition than recoverability

Premature writes - overwriting uncommitted values

Transaction T: before T and U the Transaction U: serially equivalent

balance of A was
a.setBalance(105) $100 a.setBalance(110) executions of T and U
$100 interaction between write operations
a.setBalance(105) $105 when a transaction aborts
Figure 13.12 a.setBalance(110) $110

y some database systems keep ‘before images’ and restore them

after aborts.
–e.g. $100 is before image of T’s write, $105 is before image of U’s write
–if U aborts we get the correct balance of $105,
–But if U commits and then T aborts, we get $100 instead of $110
Strict executions of transactions

y Curing premature writes:

– if a recovery scheme uses before images
Š write operations must be delayed until earlier transactions that updated
the same objects have either committed or aborted

y Strict executions of transactions

– to avoid both ‘dirty reads’ and ‘premature writes’.
Š delay both read and write operations
– executions of transactions are called strict if both read and write
operations on an object are delayed until all transactions that
previously wrote that object have either committed or aborted.
– the strict execution of transactions enforces the desired property of
isolation
13.3 Nested transactions (skip)
T : top-level transaction
T1 = openSubTransaction T2 = openSubTransaction
commit
T1 : T2 :
openSubTransaction openSubTransaction openSubTransaction
prov. commit abort
T11 : T12 : T21 :
openSubTransaction
prov. commit prov. commit prov. commit
T211 :

Figure 13.13
prov.commit

y transactions may be composed of other transactions

– several transactions may be started from within a transaction
– we have a top-level transaction and subtransactions which may have
their own subtransactions
Nested transactions

y To a parent, a subtransaction is atomic with respect

to failures and concurrent access
y transactions at the same level (e.g. T1 and T2) can
run concurrently but access to common objects is
serialised
y a subtransaction can fail independently of its parent
and other subtransactions
– when it aborts, its parent decides what to do, e.g. start another
subtransaction or give up
y The CORBA transaction service supports both flat
and nested transactions
Advantages of nested transactions (over flat ones)

y Subtransactions may run concurrently with other

subtransactions at the same level.
– this allows additional concurrency in a transaction.
– when subtransactions run in different servers, they can work in parallel.
Š e.g. consider the branchTotal operation
Š it can be implemented by invoking getBalance at every account in the
branch.
• these can be done in parallel when the branches have different servers
y Subtransactions can commit or abort independently.
– this is potentially more robust
– a parent can decide on different actions according to whether a subtransaction has
aborted or not
Commitment of nested transactions

y A transaction may commit or abort only after its child

transactions have completed.
y A subtransaction decides independently to commit
provisionally or to abort. Its decision to abort is final.
y When a parent aborts, all of its subtransactions are aborted.
y When a subtransaction aborts, the parent can decide whether
to abort or not.
y If the top-level transaction commits, then all of the
subtransactions that have provisionally committed can
commit too, provided that none of their ancestors has
aborted.
Summary on transactions

y We consider only transactions at a single server, they are:

y atomic in the presence of concurrent transactions
– which can be achieved by serially equivalent executions
y atomic in the presence of server crashes
– they save committed state in permanent storage (recovery Ch.14)
– they use strict executions to allow for aborts
y nested transactions are structured from sub-transactions
– they allow concurrent execution of sub-transactions
– they allow independent recovery of sub-transactions