Transactions and Concurrency Control

 A Transaction defines a sequence of server operations that is

guaranteed to be atomic in the presence of multiple clients
and server crash.
 All concurrency control protocols are based on serial
equivalence and are derived from rules of conflicting
operations.
 Locks used to order transactions that access the same object
according to request order.
 Optimistic concurrency control allows transactions to proceed until
they are ready to commit, whereupon a check is made to see any
conflicting operation on objects.
 Timestamp ordering uses timestamps to order transactions that
access the same object according to their starting time.
Figure 13.3
Operations in Coordinator interface

openTransaction() -> trans;

starts a new transaction and delivers a
unique TID trans. This identifier will be
used in the other operations in the
transaction.

closeTransaction(trans) -> (commit, abort);

ends a transaction: a commit return value
indicates that the transaction has
committed; an abort return value indicates
that it has aborted.

abortTransaction(trans);
aborts the transaction.
Locks

 A simple example of a serializing mechanism is the use of

exclusive locks.
 Server can lock any object that is about to be used by a
client.
 If another client wants to access the same object, it has to
wait until the object is unlocked in the end.
Figure 13.14
Transactions T and U with exclusive locks

TransactionT: TransactionU:
balance = b.getBalance() balance = b.getBalance()
b.setBalance(bal*1.1) b.setBalance(bal*1.1)
a.withdraw(bal/10) c.withdraw(bal/10)
Operations Locks Operations Locks
openTransaction
bal = b.getBalance()
lock B
b.setBalance(bal*1.1) openTransaction
a.withdraw(bal/10) Lock A bal = b.getBalance()
waits forT’s
lock onB
closeTransaction unlockA, B
lock B
b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C
closeTransaction unlockB, C
Figure 13.15
Lock compatibility

For one object Lock requested

read write
Lock already set none OK OK
read OK wait
write wait wait
An object can be read and write. From the
compatibility table, we know pairs of read operations
from different transactions do not conflict. So a
simple exclusive lock used for both read and write
reduces concurrency more than necessary. (Many
readers/Single writer)
Rules;
1.If T has already performed a read operation, then a
concurrent transaction U must not write until T
commits or aborts.
2.If T already performed a write operation, then
Shared Lock and Exclusive lock

 Locks must be obtained before read/write can begin

 If a transaction want to read and write the same object, it can either
 Obtain an X-lock before reading and unlock it immediately afterwards
 Obtain an S-lock before reading, then obtain an X-lock before writing. And
unlock it immediately afterwards.

Consider the following examples
1.A1 <- 1.A1 <- Read(X)
Read(X) 2.A1 <- A1* 1.01
2.A1 <- A1 – k 3.Write(X, A1)
3.Write(X, A1) 4.A2 <- Read(Y)
4.A2 <- 5.A2 <- A2 *
Read(Y) 1.01
5.A2 <- A2 + k 6.Write(Y, A2)
6.Write(Y, A2)
T1 (Transfer) T2 (Dividend)
Recoverability from aborts

 Servers must record the effect of all committed

transactions and none of the effects of the aborted
transactions.
 A transaction may abort by preventing it affecting
other concurrent transactions if it does so.
 Two problems associated with aborting transactions
that may occur in the presence of serially equivalent
execution of transactions:
 Dirty reads
 Premature writes
 Figure 13.11
A dirty read when transaction T aborts

TransactionT: TransactionU:
a.getBalance() a.getBalance()
a.setBalance(balance + 10) a.setBalance(balance + 20)

balance = a.getBalance()$100
a.setBalance(balance + 10)
$110
balance = a.getBalance()$110

a.setBalance(balance + 20)
$130
commit transaction
abort transaction

Dirty reads caused by a read in one transaction U

and an earlier unsuccessful write in another
transaction T on the same object.
T will be rolled back and restore the original a
value, thus U will have seen a value that never
Figure 13.12
Premature Write: Overwriting uncommitted values
TransactionT: Transaction U:
a.setBalance(105) a.setBalance(110)
$100
a.setBalance(105) $105
a.setBalance(110) $110

Premature write: related to the interaction between write

operations on the same object belonging to different
transactions.
a. If U aborts and then T commit, we got a to be correct
105.
Some systems restore value to “Before images” value for
abort action, namely the value before all the writes of a
transaction. a is 100, which is the before image of T’s
write. 105 is the before image of U’s write.
b. Consider if U commits and then T aborts, we got wrong
value of 100.
c. Similarly if T aborts then U aborts, we got 105, which
Optimistic Concurrency Control

 Kung and Robinson [1981] identified a number of inherent

disadvantages of locking and proposed an alternative
optimistic approach to the serialization of transaction that
avoids these drawbacks. Disadvantages of lock-based:
 Lock maintenance represents an overhead that is not present in
systems that do not support concurrent access to shared data.
Locking sometimes are only needed for some cases with low
probabilities.
 The use of lock can result in deadlock. Deadlock prevention
reduces concurrency severely. The use of timeout and deadlock
detection is not ideal for interactive programs.
 To avoid cascading aborts, locks cannot be released until the end
of the transaction. This may reduce the potential for concurrency.
Optimistic Concurrency Control

 It is based on observation that, in most applications,

the likelihood of two clients’ transactions accessing
the same object is low. Transactions are allowed to
proceed as though there were no possibility of
conflict with other transactions until the client
completes its task and issues a closeTransaction
request.
 When conflict arises, some transaction is generally
aborted and will need to be restarted by the client.
Optimistic Concurrency Control

 Each transaction has the following phases:

 Working phase: Each transaction has a tentative version of each
of the objects that it updates. This is a copy of the most recently
committed version of the object. The tentative version allows the
transaction to abort with no effect on the object, either during the
working phase or if it fails validation due to other conflicting
transaction. Several different tentative values of the same object
may coexist. In addition, two records are kept of the objects
accessed within a transaction, a read set and a write set containing
all objects either read or written by this transaction. Read are
performed on committed version ( no dirty read can occur) and
write record the new values of the object as tentative values which
are invisible to other transactions.
Optimistic Concurrency Control

 Validation phase: When closeTransaction request is received, the

transaction is validated to establish whether or not its operations
on objects conflict with operations of other transaction on the same
objects. If successful, then the transaction can commit. If fails, then
either the current transaction or those with which it conflicts will
need to be aborted.
 Update phase: If a transaction is validated, all of the
changes recorded in its tentative versions are made
permanent. Read-only transaction can commit immediately
after passing validation. Write transactions are ready to
commit once the tentative versions have been recorded in
permanent storage.
Validation of Transactions

 Validation uses the read-write conflict rules to ensure that

the scheduling of a particular transaction is serially
equivalent with respect to all other overlapping
transactions- that is, any transactions that had not yet
committed at the time this transaction started. Each
transaction is assigned a number when it enters the
validation phase (when the client issues a
closeTransaction). Such number defines its position in
time. A transaction always finishes its working phase after
all transactions with lower numbers. That is, a transaction
with the number Ti always precedes a transaction with
number Tj if i < j.
Table on page 547
Serializability of transaction T with respect to transaction Ti

Tv Ti Rule
write read 1.mustTi not read objects written
Tv by
read write 2.must
Tv not read objects written
Ti by
write write 3.
mustTinot write objects written
Tv and
by
Tnot
v must
write objects written
Ti by

The validation test on transaction Tv is based

on conflicts between operations in pairs of
transaction Ti and Tv, for a transaction Tv to
be serializable with respect to an overlapping
transaction Ti, their operations must conform
to the above rules.
Validation

 Backward Validation: checks the transaction undergoing

validation with other preceding overlapping transactions-
those that entered the validation phase before it.

 Forward Validation: checks the transaction undergoing

validation with other later transactions, which are still
active.
Timestamp based concurrency control

 Each transaction is assigned a unique timestamp

value when it starts, which defines its position in the
time sequence of transactions.
 The basic timestamp ordering rule is based on
operation conflicts and is very simple:
 A transaction’s request to write an object is valid only if that
object was last read and written by earlier transactions. A
transaction’s request to read an object is valid only if that
object was last written by an earlier transaction.
 This rule assume that there is only one version of each
object and restrict access to one transaction at a time.
Timestamp ordering

 Timestamps may be assigned from the server’s

clock or a counter that is incremented whenever a
timestamp value is issued.
 Each object has a write timestamp and a set of
tentative versions, each of which has a write
timestamp associated with it; and a set of read
timestamps.
 The write timestamps of the committed object is
earlier than that of any of its tentative versions, and
the set of read timestamps can be represented by its
maximum member.
Timestamp ordering

 Whenever a transaction’s write operation on an

object is accepted, the server creates a new
tentative version of the object with write timestamp
set to the transaction timestamp. Whenever a read
operation is accepted, the timestamp of the
transaction is added to its set of read timestamps.
 When a transaction is committed, the values of the
tentative version become the values of the object,
and the timestamps of the tentative version become
the write timestamp of the corresponding object.
Figure 13.29
Operation conflicts for timestamp ordering

Rule Tc Ti
1. write read Tcmust not
write
an object that has been
read by Tany
i whereTi >Tc
this requires≥ the
that
Tcmaximum read timestamp of the object.

2. write write Tcmust not

write been by anyTi whereTi >Tc
an object that has written
this requires> that
write
Tc timestamp of the committed
object.

3. read write Tcmust notread

an object that has written Ti >Tc
been by anyTi where
this requires
> write
that
Tc timestamp of the committed object.

Each request from a transaction is checked to

see whether it conforms to the operation
conflict rules. Conflict may occur when
previous done operation from other transaction
Ti is later than current transaction Tc.
 Page 551
Timestamp ordering write rule

c ≥ maximum read timestamp on D &&

c > write timestamp on committed version of D)
perform write operation on tentative version of D with write t
/* write is too late */
bort transaction Tc
 Page 551
Timestamp ordering read rule

Tc > write timestamp on committed version of D) {

et Dselected be the version of D with the maximum write timestamp ≤ T
f (Dselected is committed)
perform read operation on the version Dselected
lse
Wait until the transaction that made version Dselected commits or
then reapply the read rule
e
bort transaction Tc
Comparison of methods for Concurrency Control

 The timestamp ordering method is similar to two-phase

locking in that both use pessimistic approaches in which
conflicts between transactions are detected as each object
is accessed. On the one hand, timestamp ordering decides
the serialization order statically – when a transaction
starts. On the other hand, two-phase locking decides the
serialization order dynamically – according to the order
in which objects are accessed. Timestamp ordering, and in
particular multiversion timestamp ordering, is better than
strict two-phase locking for read-only transactions. Two-
phase locking is better when the operations in
transactions are predominantly updates.
 The pessimistic methods differ in the strategy used when a
conflicting access to an object is detected. Timestamp
ordering aborts the transaction immediately, whereas
locking makes the transaction wait – but with a possible
later penalty of aborting to avoid deadlock.
Contd.

 When optimistic concurrency control is used, all

transactions are allowed to proceed, but some are
aborted when they attempt to commit, or in forward
validation transactions are aborted earlier. This
results in relatively efficient operation when there
are few conflicts, but a substantial amount of work
may have to be repeated when a transaction is aborted.
 Historically, the predominant method of concurrency
control of access to data in distributed systems is by
locking – for example, as mentioned earlier, the CORBA
Concurrency Control Service is based entirely on the
use of locks.