Transactions and Concurrency Control

1
 Transactions and Concurrency Control - Introduction

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.

2
Banking Example

Each account is represented by a remote object whose

interface Account provides operations for making deposits
and withdrawals and for enquiring about and setting the
balance.

Each branch of the bank is represented by a remote object
whose interface Branch provides operations for creating a
new account, for looking up an account by name and for
enquiring about the total funds at that branch.

Main issue: unless a server is carefully designed, its
operations performed on behalf of different clients may
sometimes interfere with one another. Such interference may
result in incorrect values in the object.

3
Figure 13.1
Operations of the Account interface

deposit(amount)
deposit amount in the account
withdraw(amount)
withdraw amount from the account
getBalance() -> amount
return the balance of the account
setBalance(amount)
set the balance of the account to amount

Operations of the Branch interface

create(name) -> account
create a new account with a given name
lookUp(name) -> account
return a reference to the account with the given name
branchTotal() -> amount
return the total of all the balances at the branch

4
Simple Synchronization without Transactions

The use of multiple threads is beneficial to the performance. Multiple

threads may access the same objects.

For example, deposit and withdraw methods: the actions of two

concurrent executions of the methods could be interleaved arbitrarily and
have strange effects on the instance variables of the account object.

Synchronized keyword can be applied to method in Java, so only one

thread at a time can access an object.

If one thread invokes a synchronized method on an object, then that

object is locked, another thread that invokes one of the synchronized
method will be blocked.

5
Enhancing Client Cooperation by Signaling

We have seen how clients may use a server as a

means of sharing some resources. E.g. some clients
update the server’s objects and other clients access
them.

However, in some applications, threads need to
communicate and coordinate their actions.

Producer and Consumer problem.
ִWait and Notify actions.

6
Transactions

Transaction originally from database management

systems.

Clients require a sequence of separate requests to a
server to be atomic in the sense that:
ִThey are free from interference by operations being
performed on behalf of other concurrent clients; and
ִEither all of the operations must be completed
successfully or they must have no effect at all in the
presence of server crashes.

7
Atomicity

All or nothing: a transaction either completes

successfully, and effects of all of its operations are
recorded in the object, or it has no effect at all.
ִFailure atomicity: effects are atomic even when server crashes
ִDurability: after a transaction has completed successfully, all
its effects are saved in permanent storage for recover later.

Isolation: each transaction must be performed without
interference from other transactions. The intermediate
effects of a transaction must not be visible to other
transactions.

8
Figure 13.2
A client’s banking transaction

Transaction T:
a.withdraw(100);
b.deposit(100);

9
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.

10
Figure 13.4
Transaction life histories

Successful Aborted by client Aborted by server

openTransaction openTransaction openTransaction

operation operation operation
operation operation operation
server aborts
transaction
operation operation operation ERROR
reported to client
closeTransaction abortTransaction

If a transaction aborts for any reason (self abort or server abort), it must be guaranteed
that future transaction will not see the its effect either in the object or in their copies in
permanent storage.
11
Concurrency Control: the lost update problem

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) $80
c.withdraw(balance/10) $280

a, b and c initially have bank account balance are: 100, 200, and 300. T transfers an
amount from a to b. U transfers an amount from c to b.

12
Concurrency Control: The inconsistent retrievals problem

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

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

a, b accounts start with 200 both.

13
Serial equivalence

If these transactions are done one at a time in some

order, then the final result will be correct.

If we do not want to sacrifice the concurrency, an
interleaving of the operations of transactions may
lead to the same effect as if the transactions had
been performed one at a time in some order.

We say it is a serially equivalent interleaving.

The use of serial equivalence is a criterion for
correct concurrent execution to prevent lost updates
and inconsistent retrievals.
14
Figure 13.7
A serially equivalent interleaving of T and U

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
b.setBalance(balance*1.1) $242
a.withdraw(balance/10) $80
c.withdraw(balance/10) $278

15
Conflicting Operations

When we say a pair of operations conflicts we mean

that their combined effect depends on the order in
which they are executed. E.g. read and write

Three ways to ensure serializability:

ִLocking
ִTimestamp ordering
ִOptimistic concurrency control

16
Figure 13.9
Read and write operation conflict rules

Operations of different Conflict Reason

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

17
Figure 13.13
Nested transactions

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 :

prov.commit

18
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.

19
Figure 13.14
Transactions T and U with exclusive locks

Transaction T: Transaction U:
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 for T’s
lock on B
closeTransaction unlock A, B
lock B
b.setBalance(bal*1.1)
c.withdraw(bal/10) lock C
closeTransaction unlock B, C

20
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 concurrent U must not read or
write until T commits or aborts.

21
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 <- Read(X) 1. A1 <- Read(X)
2. A1 <- A1 – k 2. A1 <- A1* 1.01
3. Write(X, A1) 3. Write(X, A1)
4. A2 <- Read(Y) 4. A2 <- Read(Y)
5. A2 <- A2 + k 5. A2 <- A2 * 1.01
6. Write(Y, A2) 6. Write(Y, A2)

T1 (Transfer) T2 (Dividend)
22
 Lock-based protocol -- example

Example of schedule with locks

1. S-lock(X)
No wait: S-locks
2. A1 <- Read(X)
1. S-lock(X)
3. Unlock(X)
2. A1 <- Read(X)
4. A1 <- A1 – k
T1 waits
5. X-lock(X)
3. Unlock(X)
T1 can go ahead
4. A1 <- A1* 1.01 T2 waits

5. X-lock(X)
5. X-lock(X)
T1 6. Write(X, A1) T2
7. Unlock(X)
T2 can go ahead
8. …. 5. X-lock(X) 23
Lock based protocols -- questions

Does having locks this way guarantee

conflict serializability?

Is there any other requirements in the
order/manner of accquiring/releasing
locks?

Does it matter when to acquire locks?

Does it matter when to release locks?

24
 Lock based protocol – need for a protocol
S-lock (X)
1. A1 <- Read(X)
Unlock(X)
2. A1 <- A1 – k
X-lock (X)
S-lock (X)
Unlock(X) 3. Write(X, A1) 1. A1 <- Read(X) Unlock(X)
2. A1 <- A1* 1.01
X-lock(X)
3. Write(X, A1) Unlock(X),
S-lock(Y)
4. A2 <- Read(Y) Unlock(Y)
5. A2 <- A2 * 1.01
S-lock (Y)
6. Write(Y, A2) X-lock (Y)
Unlock(Y)
4. A2 <- Read(Y)
Unlock(Y)
5. A2 <- A2 + k Not conflict serializable.
X-lock (Y)
Unlock(Y)6. Write(Y, A2)

X : 100 -> 50 -> 50.5; Y : 200 -> 202 -> 252; X+Y = 302.5 25
Two-phase locking -- motivation

What is the problem?

When a transaction release a lock on an object , that means
other transactions can obtain a lock on it.

X-lock(X)
Write(X, 100)
Unlock(X) S-lock(X)
Read(X)
……
T1 T2

In this case, there is contention from T1 to T2

To ensure serializability, we must ensure there is no conflict
from T2 back to T1

How?

26
Two-phase locking -- motivation

Ensure that T1 does not read/write

anything that T2 read/write.
ִUnrealistic to check in real life

What is a sufficient condition then?

Ensure T1 does not read/write anything
after releasing the lock!

⇒ (basic) Two-phase locking

27
Two phase locking – definition

The basic two-phase locking (2PL) protocol

ִA transaction T must hold a lock on an item x in the
appropriate mode before T accesses x.
ִIf a conflicting lock on x is being held by another
transaction, T waits.
ִOnce T releases a lock, it cannot obtain any other
lock subsequently.

Note: a transaction is divided into two phases:
ִA growing phase (obtaining locks)
ִA shrinking phase (releasing locks)

Claim : 2PL ensures conflict serializability

28
Two phase locking – Serializability

Lock-point: the point where the transaction

obtains all the locks

With 2PL, a schedule is conflict equivalent
to a a serial schedule ordered by the lock-
point of the transactions

29
 2-phase locking -- example

1. S-lock(X)
2. A1 <- Read(X)
3. A1 <- A1 – k
4. X-lock(X) T2 waits
1. S-lock(X)
5. Write(X, A1)
6. S-lock(Y)
7. A2 <- Read(Y)
8. A2 <- A2 + k
9. X-lock(Y)
10. Write(Y, A2)
11. Unlock(X)
1. S-lock(X)
Lock point for T1 2. A1 <- Read(X)
3. A1 <- A1* 1.01
4. X-lock(X)
5. Write(X, A1)
12. Unlock(Y) T2 waits
6. S-lock(Y)

6. S-lock(Y)
7. A2 <- Read(Y)
8. A2 <- A2 * 1.01 Lock point for T2
9. X-lock(Y)
T1 10.
11.
Write(Y, A2)
Unlock(Y)
T2
12. Unlock(X) 30
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

31
Figure 13.11
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

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 existed. U is committed, so cannot be undone. U performs a
dirty read. 32
Figure 13.12
Premature Write: Overwriting uncommitted values
Transaction T: 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 is wrong and should be 100.
So to ensure correctness, write operations must be delayed until earlier transactions
that updated the same object have either committed or aborted.
33
Recover problem with 2PL

1. X-lock(X)
2. A1 <- Read(X)
3. A1 <- A1 * 10
4. Write(X, A1)
5. Unlock(X)
1. X-lock(X)
2. A2 <- Read(X)
3. A2 <- A2 + 1
4. Write(X, A2)
5. Unlock(X)
6. Commit
6. Abort!

Dirty Read problem!

There is a gap between releasing locks and the decision to commit/abort

Other transactions can still access data written by a uncomitted
transaction
34
Strict two-phase Locking Protocol

Because transaction may abort, strict execution are needed

to prevent dirty reads and premature writes, which are
caused by read or write to same object accessed by another
earlier unsuccessful transaction that already performed an
write operation.

So to prevent this problem, a transaction that needs to read
or write an object must be delayed until other transactions
that wrote the same object have committed or aborted.

Rule:

Any locks applied during the progress of a transaction are
held until the transaction commits or aborts.

35
Strict two-phase Locking Protocol

36
Figure 13.16
Use of locks in strict two-phase locking

1. When an operation accesses an object within a transaction:

(a) If the object is not already locked, it is locked and the operation proceeds.
(b) If the object has a conflicting lock set by another transaction, the
transaction must wait until it is unlocked.
(c) If the object has a non-conflicting lock set by another transaction, the
lock is shared and the operation proceeds.
(d) If the object has already been locked in the same transaction, the lock will
be promoted if necessary and the operation proceeds. (Where promotion
is prevented by a conflicting lock, rule (b) is used.)
2. When a transaction is committed or aborted, the server unlocks all objects it
locked for the transaction.

A transaction with a read lock that is shared by other transactions cannot

promote its read lock to a write lock, because write lock will conflict with other
read locks. 37
Figure 13.17
Lock class

public class Lock {

private Object object; // the object being protected by the lock
private Vector holders; // the TIDs of current holders
private LockType lockType; // the current type
public synchronized void acquire(TransID trans, LockType aLockType ){
while(/*another transaction holds the lock in conflicing mode*/) {
try {
wait();
}catch ( InterruptedException e){/*...*/ }
}
if(holders.isEmpty()) { // no TIDs hold lock
holders.addElement(trans);
lockType = aLockType;
} else if(/*another transaction holds the lock, share it*/ ) ){
if(/* this transaction not a holder*/) holders.addElement(trans);
} else if (/* this transaction is a holder but needs a more exclusive lock*/)
lockType.promote();
}
}
Continues on next slide
38
Figure 13.17
continued

public synchronized void release(TransID trans ){

holders.removeElement(trans); // remove this holder
// set locktype to none
notifyAll();
}
}

39
Figure 13.19
Deadlock with write locks

Transaction T Transaction U

Operations Locks Operations Locks

a.deposit(100); write lock A

b.deposit(200) write lock B
b.withdraw(100)
waits for U’s
a.withdraw(200); waits for T’s
lock on B
lock on A

40
Figure 13.20
The wait-for graph for Figure 13.19

Held by Waits for

A
T U T U

Waits for B
Held by

41
Figure 13.21
A cycle in a wait-for graph

42
Figure 13.22
Another wait-for graph

V T
Held by W

T Held by Held by
C
U
Held by B
U
W V
Waits for

T and W then request write locks on object C and a deadlock arises. V is

involved in two cycles.

43
Deadlock Prevention

Deadlock prevention:
ִSimple way is to lock all of the objects used by a
transaction when it starts. It should be done as an atomic
action to prevent deadlock. a. inefficient, say lock an
object you only need for short period of time. b. Hard to
predict what objects a transaction will require.
ִJudge if system can remain in a Safe state by satisfying a
certain resource request. Banker’s algorithm.
ִOrder the objects in certain order. Acquiring the locks
need to follow this certain order.

44
Safe State

System is in safe state if there exists a sequence

<P1, P2, …, Pn> of ALL the processes is the
systems such that for each Pi, the resources that Pi
can still request can be satisfied by currently
available resources + resources held by all the Pj,
with j < i.
If a system is in safe state ⇒ no
deadlocks.
If a system is in unsafe state ⇒
possibility of deadlock.
Avoidance ⇒ ensure that a system will
never enter an unsafe state.
45
Banker’s Algorithm

Let Available and Finish be vectors of length m

(resource types) and n (processes number),
respectively. Initialize:
Finish [i] = false for i = 0, 1, …, n- 1.
2. Find and i such that both:
(a) Finish [i] = false
(b) Needi ≤ Available
If no such i exists, go to step 4.
3. Available = Available + Allocationi
Finish[i] = true
go to step 2.
4. If Finish [i] == true for all i, then the system is in a
safe state. 46
Example

5 processes P0 through P4;

3 resource types:
A (10 instances), B (5instances), and C (7 instances).

Snapshot at time T0:
Allocation Max Available
ABC ABC ABC
P0 010 753 332
P1 200 322
P2 302 902
P3 211 222
P4 002 433

47
 Example

The content of the matrix Need is defined to be Max –

Allocation.
Allocation Max Available
ABC ABC ABC
Need
P0 010 753 332
ABC
P1 200 322
P0 743
P2 302 902
P1 122
P3 211 222
P2 600
P4 002 433
P3 011
P4 431

The system is in a safe state since the sequence < P1,

P3, P4, P2, P0> satisfies safety criteria.

48
Request Example

Check that Request ≤ Available (that is, (1,0,2) ≤ (3,3,2) ⇒ true.

Allocation Need Available
ABC ABC ABC
P0 0 1 0 743 230
P1 3 0 2 020
P2 3 0 1 600
P3 2 1 1 011
P4 0 0 2 431

Executing Banker’s/safety algorithm shows that sequence < P1, P3, P4, P0,
P2> satisfies safety requirement.

Can request for (3,3,0) by P4 be granted?

Can request for (0,2,0) by P0 be granted?

49
Resource-Allocation Graph and Wait-for Graph

Resource-Allocation Graph Corresponding wait-for graph

50
Deadlock Detection

Deadlock may be detected by finding cycles in the wait-for-graph. Having

detected a deadlock, a transaction must be selected for abortion to break
the cycle.
ִIf lock manager blocks a request, an edge can be added. Cycle should
be checked each time a new edge is added.
ִOne transaction will be selected to abort in case of cycle. Age of
transaction and number of cycles involved when selecting a victim

Timeouts is commonly used to resolve deadlock. Each lock is given a
limited period in which it is invulnerable. After this time, a lock becomes
vulnerable.
ִ If no other transaction is competing for the object, vulnerable object remained locked.
However, if another transaction is waiting, the lock is broken.
Disadvantages:
ִ Transaction aborted simply due to timeout and waiting transaction even if there is no
deadlock. ( may add deadlock detection)
ִ Hard to set the timeout time
51
Figure 13.23
Resolution of the deadlock in Figure 15.19

Transaction T Transaction U
Operations Locks Operations Locks

a.deposit(100); write lock A

b.deposit(200) write lock B
b.withdraw(100)
waits for U’s a.withdraw(200); waits for T’s
lock on B lock on A
(timeout elapses)
T’s lock on A becomes vulnerable,
unlock A, abort T
a.withdraw(200); write locks A
unlock A, B

52
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.

53
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.

54
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.

55
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.

56
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.
57
Table on page 547
Serializability of transaction T with respect to transaction Ti

Tv Ti Rule
write read 1. Ti must not read objects written by Tv
read write 2. Tv must not read objects written by Ti
write write 3. Ti must not write objects written by Tv and
Tv must not write objects written by Ti

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.
58
Figure 13.28
Validation of transactions

Working Validation Update

T1
Earlier committed
transactions
T2

T3

Transaction
being validated Tv

active
1
Later active
active
transactions 2

59
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.

60
Page 547-548
Validation of Transactions

Backward validation of transaction Tv

boolean valid = true;
for (int Ti = startTn+1; Ti <= finishTn; Ti++){
if (read set of Tv intersects write set of Ti) valid = false;
}

Forward validation of transaction Tv

boolean valid = true;
for (int Tid = active1; Tid <= activeN; Tid++){
if (write set of Tv intersects read set of Tid) valid = false;
}

61
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.
62
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.
63
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.

64
Figure 13.29
Operation conflicts for timestamp ordering

Rule Tc Ti
1. write read Tc must not write an object that has been read by any Ti where Ti >Tc
this requires that Tc ≥ the maximum read timestamp of the object.

2. write write Tc must not write an object that has been written by any Ti where Ti >Tc
this requires that Tc > write timestamp of the committed object.

3. read write Tc must not read an object that has been written by any Ti whereTi >Tc
this requires that Tc > write 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.
It means the request is submitted too late.
65
Figure 13.30
Write operations and timestamps

(a) T3 write (b) T3 write

T2 T1 T2 Key:
Before Before Ti

Committed
After T2 T3 After T1 T2 T3
Ti
Time Time
Tentative

object produced
(c) T3 write (d) T3 write by transaction Ti
Transaction (with write timestamp Ti)
T1 T4 T4 aborts T1<T2<T3<T4
Before Before

After T1 T3 T4 After T4

Time Time

66
Page 551
Timestamp ordering write rule

if (Tc ≥ maximum read timestamp on D &&

Tc > write timestamp on committed version of D)
perform write operation on tentative version of D with write timestamp Tc
else /* write is too late */
Abort transaction Tc

67
Page 551
Timestamp ordering read rule

if ( Tc > write timestamp on committed version of D) {

let Dselected be the version of D with the maximum write timestamp ≤ Tc
if (Dselected is committed)
perform read operation on the version Dselected
else
Wait until the transaction that made version Dselected commits or aborts
then reapply the read rule
} else
Abort transaction Tc

68
Figure 13.31
Read operations and timestamps

(b) T3 read
(a) T3 read
Key:

read read
T2 T2 T4 proceeds
proceeds Ti

Selected Committed
Selected Time
Time
Ti
(c) T3 read (d) T3 read
Tentative

read waits Transaction object produced

T1 T2 T4 aborts by transaction Ti
(with write timestamp Ti)
T1 < T2 < T3 < T4
Selected
Time Time

69
Exercise

Timestamps and versions of objects

T U A B C
RTS WTS RTS WTS RTS WTS
{} S {} S {} S
openTransaction
bal = b.getBalance()
openTransaction
b.setBalance(bal*1.1)
bal = b.getBalance()

a.withdraw(bal/10)
commit
bal = b.getBalance()
b.setBalance(bal*1.1)
c.withdraw(bal/10)

S<T<U 70
Figure 13.32
Timestamps in transactions T and U

Timestamps and versions of objects

T U A B C
RTS WTS RTS WTS RTS WTS
{} S {} S {} S
openTransaction
bal = b.getBalance() {T}
openTransaction
b.setBalance(bal*1.1) S, T
bal = b.getBalance()
wait for T
a.withdraw(bal/10) S, T
commit T T
bal = b.getBalance() {U}
b.setBalance(bal*1.1) T, U
c.withdraw(bal/10) S, U

S<T<U 71
 Test Your Understanding

1. A server manages the objects a1, a2, ... an. The server provides two
operations for its clients:
read (i) returns the value of ai;
write(i, Value) assigns Value to ai.
The transactions T and U are defined as follows:
T: x = read(j); y = read (i); write(j, 44); write(i, 33);
U: x = read(k); write(i, 55); y = read (j); write(k, 66).

Give three serially equivalent interleavings of the transactions T and

U.

72
 Test Your Understanding
2. Consider the use of timestamp ordering with each of the example
interleavings of transactions T and U in Exercise 13.9. Initial values of
ai and aj are 10 and 20, respectively, and initial read and write
timestamps are t0. Assume that each transaction opens and obtains a
timestamp just before its first operation; for example, in (a) T and U get
timestamps t1 and t2 respectively, where t0 < t1 < t2. Describe in order
of increasing time the effects of each operation of T and U. For each
operation, state the following:

(i) whether the operation may proceed according to the write or

read rule.
(ii) timestamps assigned to transactions or objects.
(iii)creation of tentative objects and their values.
What are the final values of the objects and their timestamps?

73