Module 6: Distributed

Transactions
 Outline
• Transaction And Concurrency
Control- Nested Transactions- Locks -
Optimistic Concurrency Control-
Timestamp Ordering.
• Distributed Transactions- Flat and
Nested, Atomic, Two phase Commit
protocol, Concurrency Control
SCOPE, VIT Chennai
 Text Book
• Coulouris, G. (2012). Distributed
systems. Boston: Addison-Wesley

SCOPE, VIT Chennai

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.

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 Banking Example
• Main issue: unless a server is
carefully designed, the operations
performed on behalf of different
clients may sometimes interfere with
one another.
• Such interference may result in
incorrect values in the object.
SCOPE, VIT Chennai
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

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 Simple Synchronization
without Transactions
• 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.
SCOPE, VIT Chennai
Enhancing Client Cooperation
by Signaling
• 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.

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

A client’s banking transaction

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

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 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 its effect either in the object or
in their copies in permanent storage.

SCOPE, VIT Chennai

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.

SCOPE, VIT Chennai

 The lost update problem
• The lost update problem is illustrated by the following pair of
transactions on bank accounts A, B and C, whose initial balances
are $100, $200 and $300, respectively.
• Transaction T transfers an amount from account A to account B.
• Transaction U transfers an amount from account C to account B.
• In both cases, the amount transferred is calculated to increase
the balance of B by 10%.
• The net effects on account B of executing the transactions T and
U should be to increase the balance of account B by 10% twice,
so its final value is $242.

SCOPE, VIT Chennai

 The lost update problem
• Now consider the effects of allowing the transactions T
and U to run concurrently, as in Figure.
• Both transactions get the balance of B as $200 and then
deposit $20.
• The result is incorrect, increasing the balance of account B
by $20 instead of $42.
• This is an illustration of the ‘lost update’ problem.
• U’s update is lost because T overwrites it without seeing it.
• Both transactions have read the old value before either
writes the new value.

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 The inconsistent retrievals
problem
• The balances of the two bank accounts, A and B,
are both initially $200.
• The result of branchTotal includes the sum of A
and B as $300, which is wrong.
• This is an illustration of the ‘inconsistent
retrievals’ problem.
• W’s retrievals are inconsistent because V has
performed only the withdrawal part of a transfer
at the time the sum is calculated.

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 Serial equivalence
• 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.

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 Nested transactions
T : top-level transaction
T1 = openSubTransaction T2 = openSubTransaction
commit
T1 : T2 :
openSubTransaction openSubTransaction openSubTransaction
prov. commit abort
T 11 : T12 : T21 :
openSubTransaction
prov. commit prov. commit prov. commit
T 211 :

prov.commit

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

 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.
SCOPE, VIT Chennai
 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

SCOPE, VIT Chennai

 Shared Lock and Exclusive
lock
 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)

SCOPE, VIT Chennai

 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)
T1 waits 4. A1 <- A1 – k
5. X-lock(X)
3. Unlock(X)
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)
SCOPE, VIT Chennai
 Lock based protocol – need
S-lock (X)
for a protocol
1. A1 <- Read(X)
Unlock(X) 2. A1 <- A1 – k
3. Write(X, A1)
X-lock (X)
S-lock (X)
Unlock(X) 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
X-lock(Y)
6. Write(Y, A2) Unlock(Y),
S-lock (Y)

Unlock(Y)
4. A2 <- Read(Y)
5. A2 <- A2 + k
X-lock (Y)
6. Write(Y, A2)
Unlock(Y)

X : 100 -> 50 -> 50.5; Y : 200 -> 202 -> 252; X+Y = 302.5

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 Two-phase locking --
motivation
• 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
• Ensure that T1 does not read/write
anything that T2 read/write.
• Unrealistic to check in real life

SCOPE, VIT Chennai

 Two-phase locking --
motivation
• What is a sufficient condition then?
• Ensure T1 does not read/write
anything after releasing the lock!
•  (basic) Two-phase locking

SCOPE, VIT Chennai

 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.
SCOPE, VIT Chennai
 Two phase locking –
definition
• Note: a transaction is divided into
two phases:
• A growing phase (obtaining locks)
• A shrinking phase (releasing locks)
• Claim : 2PL ensures conflict
serializability

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 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.
SCOPE, VIT Chennai
 Premature Write: Overwriting
uncommitted values
$100 Transaction T: Transaction U:
a.setBalance(105) a.setBalance(110)

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.
SCOPE, VIT Chennai
 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.

SCOPE, VIT Chennai

 Strict two-phase Locking
Protocol
• 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.

SCOPE, VIT Chennai

Strict two-phase Locking
Protocol

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 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();
}
}

SCOPE, VIT Chennai

• public synchronized void release(TransID trans ){
• holders.removeElement(trans); // remove this holder
• // set locktype to none
• notifyAll();
• }
• }

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

 The wait-for graph

Held by Waits for

A
T U T U

Waits for B
Held by

SCOPE, VIT Chennai

A cycle in a wait-for graph
U

SCOPE, VIT Chennai

 Another wait-for graph

V T
Held by W

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

V is involved in two cycles.

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

SCOPE, VIT Chennai

 Deadlock Prevention
• Order the objects in certain manner. Acquiring
the locks need to follow this certain order.
• Judge if system can remain in a Safe state by
satisfying a certain resource request. Banker’s
algorithm.

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

 Banker’s Algorithm
1. 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

SCOPE, VIT Chennai

 Example
• 5 processes P0 through P4;
• 3 resource types:
A (10 instances), B (5instances), and C (7 instances).
• Snapshot at time T0:
Allocation MaxAvailable
ABC ABC ABC
P0 0 1 0 7 5 3 3 3 2
P1 2 0 0 3 2 2
P2 3 0 2 9 0 2
P3 2 1 1 2 2 2
P4 0 0 2 4 3 3

SCOPE, VIT Chennai

 Optimistic Concurrency
Control
• 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.

SCOPE, VIT Chennai

• 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

SCOPE, VIT Chennai

 Optimistic Concurrency
Control
• Each transaction has the following
phases
• Working phase
• Validation phase
• Update phase

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

 Validation of transactions
Working Validation Update

T1
Earlier committed
transactions
T2

T3

Transaction
being validated Tv

active
1
Later active
active
transactions 2

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

 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.

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

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

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.

SCOPE, VIT Chennai

 Write operations and
(a) T3 write
timestamps (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
T1 T4 T4 aborts T1<T2<T3<T4
Before Before

After T1 T3 T4 After T4

Time Time

SCOPE, VIT Chennai

 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

SCOPE, VIT Chennai

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

SCOPE, VIT Chennai

 Read operations and
(a) T3 read
timestamps (b) 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

T1 T2 T4 aborts

Selected
Time Time

SCOPE, VIT Chennai

SCOPE, VIT Chennai