1. Slides for Chapter 13: Transactions and Concurrency Control
From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design
Edition 3, © Addison-Wesley 2005
Concurrency control directly related to multithreading issues

2. Introduction to transactions
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
Recoverable objects
can be recovered after their server crashes
objects are stored in permanent storage
Failure model
transactions deal with crash failures of processes and omission failures of communication
Designed for an asynchronous system
omission faults in disks - use stable storage or mirror disks
recoverability ... need to replace the crashed process with another copy so they have to live on a disk to survive the crash •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

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
What’s missing are synchronized methods.
If two accounts trying to talk to the account object, need to provide synchronization
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

4. Figure 13.2 A client’s banking transaction
Transaction T:
a.withdraw(100);
b.deposit(100);
c.withdraw(200);
b.deposit(200);
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

5. Atomic operations at server
when a server uses multiple threads it can perform several client operations concurrently
if we allowed deposit and withdraw to run concurrently we could get inconsistent results
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
atomic operations are free from interference from concurrent operations in other threads.
use any available mutual exclusion mechanism (e.g. mutex)
RemoteException
Nice way of doing error handling
Leads you into a false sense of security -- doesn’t mean you didn’t go flying by important code when the exception was thrown.
Part of the RMI tools
The remote method call looks like a local method call
Because it really is remote, the other machine might be down so you might get a remote exception
Might have to try again.
Complicates the client design. •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

6. Client cooperation by means of synchronizing server operations
servers with multiple threads require atomic objects
but in some applications, clients depend on one another to progress
e.g. one is a producer and another a consumer
e.g. one sets a lock and the other waits for it to be released
it would not be a good idea for a waiting client to poll the server to see whether a resource is yet available
it would also be unfair (later clients might get earlier turns)
Java wait and notify methods allow threads to communicate with one another and to solve these problems
e.g. when a client requests a resource, the server thread waits until it is notified that the resource is available •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

7. 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.
What class is responsible for making sure the transaction works properly?
In responsibility driven design ...
The coordinator is responsible for making sure the transaction has the ACID properties
Powerful thing going on with a simple interface.
abort is sometimes called rollback
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

8. Figure 13.4 Transaction life histories
Successful
Aborted by client
Aborted by server
openTransaction
operation
server aborts
transaction
operation ERROR
reported to client
closeTransaction
abortTransaction
different ways a transaction might proceed
closeTransaction might be called commit
Server might choose to abort it.
In optimistic concurrency control, it might fail validation at the end, server aborts it. and reports to client.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

9. Figure 13.5 The lost update problem
Transaction T :
balance = b.getBalance();
b.setBalance(balance*1.1);
a.withdraw(balance/10) U
c.withdraw(balance/10)
balance = b.getBalance();
$200
$220
$80
$280
You wouldn’t have these problems if you were just doing one transaction at a time.
Trying to maximize the concurrency.
We’ll allow a certain amount of interleaving of operations and put restrictions on what we’ll allow.
The second chronologically setBalance is a lost update.
We need to prevent that.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

10. Figure 13.6 The inconsistent retrievals problem
Transaction V :
a.withdraw(100)
b.deposit(100) W
aBranch.branchTotal()
a.withdraw(100);
$100
total = a.getBalance()
total = total+b.getBalance()
$300
total = total+c.getBalance()
branchTotal is a readonly operation. Sounds safe.
Finish the total after the withdrawal from a but before the deposit in b
inconsistent retrieval
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

11. Serial equivalence
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
the same effect means
the read operations return the same values
the instance variables of the objects have the same values at the end
Serial equivalence -- it’s ok to interleave operations but the result must be as if they were serial as far as correctness is concerned.
The transactions are scheduled to avoid overlapping access to the accounts accessed by both of them •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

12. Figure 13.7 A serially equivalent interleaving of T and U
Transaction T :
balance = b.getBalance()
b.setBalance(balance*1.1)
a.withdraw(balance/10) U
c.withdraw(balance/10)
balance = b.getBalance()
$200
$220
$242
$80
$278
By grouping certain statements, I avoid interleaving. That is, I get the serial equivalence.
If the smae objects are in different transactions, they need to be treated as serial.
Different objects in those transactions ... they can be concurrent any way at all.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

13. Figure 12.8 A serially equivalent interleaving of V and W
Transaction V :
a.withdraw(100);
b.deposit(100) W
aBranch.branchTotal()
$100
$300
total = a.getBalance()
total = total+b.getBalance()
$400
total = total+c.getBalance()
...
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

14. Figure 13.9 Read and write operation conflict rules
Operations of different
transactions
Conflict
Reason
read No
Because the effect of a pair of
operations
does not depend on the order in which they are
executed
write
Yes
Because the effect of a
and a
operation
depends on the order of their execution
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

15. Serial equivalence defined in terms of conflicting operations
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
Serial equivalence is used as a criterion for designing concurrency control schemes
T’s write(i) conflicts with U’s read (i)
U’s read (j) and write(j) conflict with T’s write(j) •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

16. Figure 13.10 A non-serially equivalent interleaving of operations of transactions T and U: U
x = read(i)
write(i, 10)
y = read(j)
write(j, 30)
write(j, 20)
z = read (i)
Going to explain HOW to enforce serial equivalence?
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

17. Figure 13.11 A dirty read when transaction T aborts:
a.getBalance()
a.setBalance(balance + 10) U
a.setBalance(balance + 20)
balance = a.getBalance()
$100
$110
$130
commit transaction
abort transaction
Serial equivalence isn’t quite enough. Also need to prevent dirty reads.
The whole transaction is kind of interleaved because I’m not doing a commit after the a.setBalance. In fact, eventually, I abort it and the other process read something that shouldn’t have existed.
Cascading abort is not good where U moves its commit down farther. In fact, you can’t commit on an uncommitted step.
So, need to move the abort up ... transaction manager shouldn’t allow a read of an uncommitted value.
Cascading abort is not a safety problem; it’s a liveness problem.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

18. Recoverability of transactions
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
e.g. U waits until T commits or aborts
if T aborts then U must also abort
Potential problem is cascading aborts
You’ll probably never have to implement the transaction manager yourself. There are lots of them out there. Your data base is done for you. Messaging Middleware does this sort of thing for you.
The same ideas apply to multithreaded programming which you *will* do. •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

19. Cascading aborts
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.
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.
Avoidance of cascading aborts is a stronger condition than recoverability •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

20. Strict executions of transactions
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
Tentative versions are used during progress of a transaction
objects in tentative versions are stored in volatile memory
tentative versions are in volatile memory
updates to tentative versions, subsequent reads from tentative versions
throw away if it aborts
copy to permanent storage if it commits
Don’t read an uncommitted value ... that’s what this concept enforces.
There are copies of the object floating around
In multithreaded programming, you can protect yourself ... two threads can’t corrupt an object if it’s not the same object. But then you have to “merge” the results •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

21. Figure 13.14 Transactions T and U with exclusive locks:
balance = b.getBalance()
b.setBalance(bal*1.1)
a.withdraw(bal/10) U
c.withdraw(bal/10)
Operations
Locks
openTransaction
bal = b.getBalance()
lock B A
waits for ’s
lock on
closeTransaction
unlock , C
The locking does the mutual exclusion support you need to get serial equivalence and avoid dirty reads.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

22. Figure 13.13 Nested transactions
T : top-level transaction T 1
= openSubTransaction 2
openSubTransaction : 11 12
211 21
prov.commit
prov. commit
abort
commit
Nested transactions allow more concurrency
When a subtransaction commits, it really provisionally commits because the parent transaction may abort later.
The parent can retry a subtransaction that aborted rather than the parent automatically aborting because of the abort.
It’s up to the application programmer but they have added flexibility.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

23. Nested transactions (13.3)
To a parent, a subtransaction is atomic with respect to failures and concurrent access
transactions at the same level (e.g. T1 and T2) can run concurrently but access to common objects is serialised
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 •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

24. Advantages of nested transactions (over flat ones)
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.
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 •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

25. Commitment of nested transactions
A transaction may commit or abort only after its child transactions have completed.
A subtransaction decides independently to commit provisionally or to abort. Its decision to abort is final.
When a parent aborts, all of its subtransactions are aborted.
When a subtransaction aborts, the parent can decide whether to abort or not.
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. •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

26. Summary on transactions
We consider only transactions at a single server, they are:
atomic in the presence of concurrent transactions
which can be achieved by serially equivalent executions
atomic in the presence of server crashes
they save committed state in permanent storage (recovery Ch.13)
they use strict executions to allow for aborts
they use tentative versions to allow for commit/abort
nested transactions are structured from sub-transactions
they allow concurrent execution of sub-transactions
they allow independent recovery of sub-transactions •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

27. Introduction to concurrency control
Transactions must be scheduled so that their effect on shared objects is serially equivalent
A server can achieve serial equivalence by serialising access to objects, e.g. by the use of locks
for serial equivalence,
(a) all access by a transaction to a particular object must be serialized with respect to another transaction’s access.
(b) all pairs of conflicting operations of two transactions should be executed in the same order.
If T was allowed to access A then unlock it then access B than access A again
Another transaction U might access A while it was unlocked so we have T-> and U-> T at A
two-phase locking
can ensure strict ordering
first thing, transaction gets all the locks it’s going to need
that’s the growing
release all the locks at once -- that’s the shrinking phase
Pessimistic control use strict two-phase locking
How do you get all your locks simultaneously?
to ensure (b), a transaction is not allowed any new locks after it has released a lock
Two-phase locking - has a ‘growing’ and a ‘shrinking’ phase •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

28. • Lock compatibility For one object Lock requested read write
Lock already set
none OK
wait
Figure 13.15
two types of locks -- read locks and write locks •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

29. 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.
Here’s all the rules.
lock is “shared” -- both share a read lock
“promoted” -- take a read lock and it becomes a write lock
This scheme does not prevent deadlock because of b ... while waiting but already have some locks
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

30. Figure 13.17 Lock class Continues on next slide 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();
Don’t use this code.
this is a place to start for a lockmanager but it does not detect deadlock
Also you need to make the notifyall on the next slide more complicated.
Here is how to implement a lock:
I’m not using the one built into Java; I’m trying to build my own locking scheme.
We’ll have a class called lock.
The code is implementing therules of 2-phase locking.
The client is going to talk to the lockmanager, not the lock.
Continues on next slide
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

31. Figure continued
public synchronized void release(TransID trans ){
holders.removeElement(trans); // remove this holder
// set locktype to none
notifyAll(); }
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

32. Figure 13.18 LockManager class
public class LockManager {
private Hashtable theLocks;
public void setLock(Object object, TransID trans, LockType lockType){
Lock foundLock;
synchronized(this){
// find the lock associated with object
// if there isn’t one, create it and add to the hashtable }
foundLock.acquire(trans, lockType);
// synchronize this one because we want to remove all entries
public synchronized void unLock(TransID trans) {
Enumeration e = theLocks.elements();
while(e.hasMoreElements()){
Lock aLock = (Lock)(e.nextElement());
if(/* trans is a holder of this lock*/ ) aLock.release(trans);
I’m always in the context of a transaction when I call the lockmanager.
This code works but it’s naive for 2 reasons.
1. no deadlock detection
2. on p. 489 where the book talks about this code
What’s the consequence of a write transaction in the presence of a steady trickle of reads.
Read locks can be shared.
The write has to wait until the reads are done which are never done.
The write is starved.
the problem is created by the notifyAll in the release method.
If more complicated logic, I’d call notify on the transaction that wants the write, rather than notify all.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

33. Figure 13.19 Deadlock with write locks
Transaction T U
Operations
Locks
a.deposit(100);
write lock A
b.deposit(200) B
b.withdraw(100)
waits for ’s
a.withdraw(200);
lock on
Java lets this hang forever.
1. have a timeout scheme
2. detect deadlock by doing graph theory, analyzing the graph, seeing you have a cycle in the graph, choose one and force it to abort. It’s not hard to do on a single box. It IS harder in a distributed environment.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

34. Figure 13.20 The wait-for graph for Figure 13.19B A
Waits for
Held by T U
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

35. Figure 13.21 A cycle in a wait-for graphV T
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

36. Another wait-for graphC T U V
Held by W B
Waits for
Figure 13.22
T, U and V share a read lock on C and
W holds write lock on B (which V is waiting for)
T and W then request write locks on C and deadlock occurs e.g. V is in two cycles - look on the left
the deadlock is shown on the left. T and W start waiting for T, U and W •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

37. Figure 13.23 Resolution of the deadlock in Figure 15.19
Transaction T
Transaction U
Operations
Locks
a.deposit(100);
write lock A
b.deposit(200) B
b.withdraw(100)
waits for U ’s
a.withdraw(200);
waits for T’s
lock on
(timeout elapses)
T’s lock on
becomes vulnerable,
unlock
, abort T
write locks ,
This uses a timeout scheme.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

38. Deadlock prevention is unrealistic
e.g. lock all of the objects used by a transaction when it starts
unnecessarily restricts access to shared resources.
it is sometimes impossible to predict at the start of a transaction which objects will be used.
Deadlock can also be prevented by requesting locks on objects in a predefined order
but this can result in premature locking and a reduction in concurrency
Not sure deadlock prevention is really unrealistic.
Dave L. thinks that with clever design it IS possible.
More elaborate schemes use queuing theory.
Good to try to prevent it and in some situations it is realistic.
Some argue it’s not worth the performance hit to get all your locks at the outset before proceeding.
Database point of view ... it’s worth it to maximize concurrency and risk deadlock.
“predefined order” -- suppose you have banking accounts and always have to hit them in alphabetical order ... you would avoid deadlock •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

39. • Lock timeouts can be used to resolve deadlocks Timeouts on locks
each lock is given a limited period in which it is invulnerable.
after this time, a lock becomes vulnerable.
provided that no other transaction is competing for the locked object, the vulnerable lock is allowed to remain.
but if any other transaction is waiting to access the object protected by a vulnerable lock, the lock is broken
The transaction whose lock has been broken is aborted
problems with lock timeouts
locks may be broken when there is no deadlock
if the system is overloaded, lock timeouts will happen more often and long transactions will be penalised
it is hard to select a suitable length for a timeout •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

40. Optimistic concurrency control
the scheme is called optimistic because the likelihood of two transactions conflicting is low
a transaction proceeds without restriction until the closeTransaction (no waiting, therefore no deadlock)
it is then checked to see whether it has come into conflict with other transactions (validation)
when a conflict arises, a transaction is aborted
With optimistic scheme, whichever validates first will pass and commit, the other will abort. •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

41. Optimistic concurrency control
Working phase
the transaction uses a tentative version of the objects it accesses (dirty reads can’t occur as we read from a committed version or a copy of it)
the coordinator records the readset and writeset of each transaction
Validation phase
at closeTransaction the coordinator validates the transaction (looks for conflicts)
if the validation is successful the transaction can commit.
if it fails, either the current transaction, or one it conflicts with is aborted
With optimistic scheme, whichever validates first will pass and commit, the other will abort.
Update phase
If validated, the changes in its tentative versions are made permanent.
read-only transactions can commit immediately after passing validation. •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

42. Validation of transactionsTv Ti
Rule
write
read 1.
must not read objects written by 2. 3.
must not write objects written by
and
must
not write objects written by
page 498
Validation can be simplified by omitting rule 3 (if no overlapping of validate and update phases)
transaction numbers assigned in ascending sequence,
indicate position in time (finish working phase after others with lower numbers)
You can omit rule 3 if you force serializatoin in the final phase.
Transactions can go concurrently thru the working phase.
If you assume the final phase is serial (very quick), then you lock out others during validation and commit phases
I can’t read what these guys are writing.
I compare to see if they have the same objects. If so, ... (saying something about backward validation and forward validation but I missed it ...)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

43. Figure 13.28 Validation of transactions
Earlier committed
transactions
Working
Validation
Update T 1 v
Transaction
being validated 2 3
Later active
active
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

44. Backward 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; }
(Page 499)
to carry out this algorithm, we must keep write sets of recently committed transactions
startTn is the biggest transaction number assigned to some other committed transaction when Tv started its working phase
finishTn is biggest transaction number assigned to some other committed transaction when Tv started its validation phase
In figure, StartTn + 1 = T2 and finishTn = T3. In backward validation, the read set of Tv must be compared with the write sets of T2 and T3.
the only way to resolve a conflict is to abort Tv
must keep write sets of recently committed transactions •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

45. Go back to conflict rules and Fig. 13.28
Forward validation
the scheme must allow for the fact that read sets of active transactions may change during validation
Go back to conflict rules and Fig
Rule 1. the write set of Tv is compared with the read sets of all overlapping active transactions
In Figure 13.28, the write set of Tv must be compared with the read sets of active1 and active2.
Rule 2. (read Tv vs write Ti) is automatically fulfilled because the active transactions do not write until after Tv has completed.
as the other transactions are still active, we have a choice of aborting them or Tv
if we abort Tv, it may be unnecessary as an active one may anyway abort
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; }
read only transactions always pass validation
the scheme must allow for the fact that read sets of active transactions may change during validation
as the other transactions are still active, we have a choice of aborting them or Tv
(if we abort Tv, it may be unnecessary as an active one may anyway abort)
read only transactions always pass validation •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000

46. Comparison of methods for concurrency control
pessimistic approach (detect conflicts as they arise)
timestamp ordering: serialisation order decided statically
locking: serialisation order decided dynamically
optimistic methods
all transactions proceed, but may need to abort at the end
efficient operations when there are few conflicts, but aborts lead to repeating work
the above methods are not always adequate e.g.
in cooperative work there is a need for user notification
applications such as cooperative CAD need user involvement in conflict resolution
timestamp ordering is another pessimistic approach
didn’t talk about it because he hasn’t worked with one
He doesn’t think it’s that common but it’s another scheme that works.
The recovery scheme that chapter 13 talks about applies equally well to single box as well as distributed boxes.
There are other kinds of transactions that don’t fit into this scheme at all.
Code Version Control System.
Both trying to check in code.
The USERS need to cooperate.
CAD systems can do the same thing. •
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn © Addison-Wesley Publishers 2000