Chapter 11 Trans Concur

Slides for Chapter 11: Transactions and Concurrency Control
From Coulouris, Dollimore and Kindberg
Distributed Systems: Concepts and Design

Edition 4, Addison-Wesley 2005
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.
Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 Addison-Wesley Publishers 2005
Simple synchronization (without transactions):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.
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
Simple Synchronization without Transactions:Atomic operations at the server
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.
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 servers 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 in java They must be used with synchronized methods of an object
Transactions
Transaction originally from database management systems. A transaction is a sequence of server operations that is guaranteed by the server to be atomic in the presence of multiple clients and server crashes. 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.
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.
Properties(ACID)
Atomicity all or nothing Consistency a transaction must move the system from one consistent state to another Isolation intermediate effects must be invisible to other clients Durability
Figure 13.2 A clients banking transaction
Transaction T: a.withdraw(100); b.deposit(100); c.withdraw(200); b.deposit(200);
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.
Figure 13.4 Transaction life histories
Successful openTransaction operation operation
Aborted by client openTransaction operation operation server aborts transaction
Aborted by server openTransaction operation operation
operation closeTransaction
operation abortTransaction
operation ERROR reported to client
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.
Transactions
Concurrency control
Recoverability from aborts
Lost update problem
Inconsistent retrievals
Serial equivalence
Conflicting operations
dirty reads
Locks
Recoverability of transactions
Optimistic concurrency control
Cascading aborts
Timestamp ordering
Premature writes
Strict execution of transactions
Tentative versions
Concurrency Control: the lost update problem

Transaction T : balance = b.getBalance(); b.setBalance(balance*1.1); a.withdraw(balance/10) balance = b.getBalance(); $200 balance = b.getBalance(); b.setBalance(balance*1.1); b.setBalance(balance*1.1); a.withdraw(balance/10) $220 $80 c.withdraw(balance/10) $280 $200 $220 Transaction U: balance = b.getBalance(); b.setBalance(balance*1.1); c.withdraw(balance/10)
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.
Concurrency Control: The inconsistent retrievals problem
Transaction V: a.withdraw(100) b.deposit(100) a.withdraw(100); $100
Transaction W: aBranch.branchTotal()
total = a.getBalance() total = total+b.getBalance() total = total+c.getBalance() b.deposit(100) $300
$100
$300
a, b accounts start with 200 both.

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.
A serially equivalent interleaving of T and U
Transaction T: balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) balance = b.getBalance() b.setBalance(balance*1.1) $200 $220
Transaction U: balance = b.getBalance() b.setBalance(balance*1.1) c.withdraw(balance/10)
balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) $80
$220 $242
c.withdraw(balance/10)
$278
A serially equivalent interleaving of V and W
Transaction : V a.withdraw(100); b.deposit(100) a.withdraw(100); b.deposit(100) $100 $300
Transaction : W aBranch.branchTotal()
total = a.getBalance() total = total+b.getBalance() total = total+c.getBalance() ...
$100 $400
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
Read and write operation conflict rules
Operations of different Conflict transactions read read No
Reason Because the effect of a pair of read operations does not depend on the order in which they are executed Because the effect of a read and a write operation depends on the order of their execution Because the effect of a pair of write operations depends on the order of their execution
read
write
write
write
Yes
Yes
A non-serially equivalent interleaving of operations of transactions T and U
Transaction T : x = read(i) write(i, 10)
Transaction U :
y = read(j) write(j, 30) z = read (i)
write(j, 20)
T: x=read(i);writte(i,10);write(j,200; U:y=read(j);write(j,30);z=read(i);
Recoverability from aborts: A dirty read when transaction T aborts
Transaction :T a.getBalance() a.setBalance(balance + 10) balance = a.getBalance() a.setBalance(balance + 10) $100 $110
Transaction :U a.getBalance() a.setBalance(balance + 20)
balance = a.getBalance()
$110 $130
a.setBalance(balance + 20)
commit transaction abort transaction
Figure 13.13 Nested transactions
T : top-level transaction T1 = openSubTransaction T2 = openSubTransaction T1 :

openSubTransaction T11 : prov. commit T12 : prov. commit openSubTransaction
T2 :
openSubTransaction
commit
prov. commit
T21 : openSubTransaction T211 :
abort
prov. commit
prov.commit
Committing Nested Transactions
A transaction may commit or abort only after its child transactions have completed When a sub-transaction completes, it makes an independent decision either to commit provisionally or to abort. Its decision to abort is final. When a parent aborts, all of its sub-transactions are aborted. When a sub-transaction aborts, the parent can decide whether to abort or not. If a top-level transaction commits, then all of the subtransactions that have provisionally committed can commit too, provided that non of their ancestors has aborted.
Transactions
24
Concurrency Control
General organization of managers for handling transactions.

Transactions
25
Schemes for Concurrency control
Locking
Server attempts to gain an exclusive lock that is about to be used by one of its operations in a transaction. Can use different lock types (read/write for example) Two-phase locking
Optimistic concurrency control Time-stamp based concurrency control
Transactions
26
Locks
A simple example of a serializing mechanism is the use of exclusive locks. Server can lock any object that is about to be used by a client. If another client wants to access the same object, it has to wait until the object is unlocked in the end.
Figure 13.14 Transactions T and U with exclusive locks

Transaction T: balance = b.getBalance() b.setBalance(bal*1.1) a.withdraw(bal/10) Transaction U: balance = b.getBalance() b.setBalance(bal*1.1) c.withdraw(bal/10)
Operations
openTransaction bal = b.getBalance() b.setBalance(bal*1.1)
Locks
lock B
Operations
Locks
openTransaction
a.withdraw(bal/10)
closeTransaction
Lock A
unlock A, B
bal = b.getBalance()
waits for Ts lock on B lock B
b.setBalance(bal*1.1) c.withdraw(bal/10)
closeTransaction
lock C
unlock B, C
Two-Phase Locking (1)
In two-phase locking, a transaction is not allowed to acquire any new locks after it has released a lock
Transactions
29
Strict Two-Phase Locking (2)
Strict two-phase locking.
Transactions
30
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.
Transactions
31
Figure 13.15 Lock compatibility For one object Lock already set Lock requested read write
none
read
OK
OK
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.
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. 2. 3. 4. 5. 6.
A1 <- Read(X) A1 <- A1 k Write(X, A1) A2 <- Read(Y) A2 <- A2 + k Write(Y, A2) T1 (Transfer)
1. 2. 3. 4. 5. 6.
A1 <- Read(X) A1 <- A1* 1.01 Write(X, A1) A2 <- Read(Y) A2 <- A2 * 1.01 Write(Y, A2) T2 (Dividend)
Lock-based protocol -- example
Example of schedule with locks

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

5. X-lock(X) 5. X-lock(X) T2 5. X-lock(X)
T2 waits
T1 6. Write(X, A1) 7. Unlock(X) 8. .
T2 can go ahead
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?
Lock based protocol need for a protocol

S-lock (X)
Unlock(X)
1. A1 <- Read(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)
S-lock (X)
2. A1 <- A1 k X-lock (X) Unlock(X) 3. Write(X, A1)
S-lock (Y)
4. A2 <- Read(Y) 5. A2 <- A2 + k Not conflict serializable. X-lock (Y) Unlock(Y)6. Write(Y, A2)
Unlock(Y)
5. A2 <- A2 * 1.01 (Y) 6. Write(Y, A2) X-lock Unlock(Y)
X : 100 -> 50 -> 50.5; Y : 200 -> 202 -> 252; X+Y = 302.5
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) T1
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?
S-lock(X) Read(X) T2
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
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
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 lockpoint of the transactions
2-phase locking -- example

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Lock point for T1 S-lock(X) A1 <- Read(X) A1 <- A1 k X-lock(X) Write(X, A1) S-lock(Y) A2 <- Read(Y) A2 <- A2 + k X-lock(Y) Write(Y, A2) Unlock(X) 1. S-lock(X)
T2 waits
12. Unlock(Y)
1. 2. 3. 4. 5. 6. 6. 7. 8. 9. 10. 11. 12.
S-lock(X) A1 <- Read(X) A1 <- A1* 1.01 X-lock(X) Write(X, A1) S-lock(Y) S-lock(Y) A2 <- Read(Y) A2 <- A2 * 1.01 X-lock(Y) Write(Y, A2) Unlock(Y) Unlock(X)
T2 waits
Lock point for T2
T1
T2
Servers must record the effect of all committed transactions and none of the effects of the aborted transactions. A transaction may abort by preventing it affecting other concurrent transactions if it does so. Two problems associated with aborting transactions that may occur in the presence of serially equivalent execution of transactions:
Dirty reads Premature writes
Figure 13.11 A dirty read when transaction T aborts Transaction T: a.getBalance() a.setBalance(balance + 10) balance = a.getBalance() a.setBalance(balance + 10) $100 $110 balance = a.getBalance() a.setBalance(balance + 20) commit transaction $110 $130 Transaction U: a.getBalance() a.setBalance(balance + 20)
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 Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4 dirty read. Addison-Wesley Publishers 2005
Figure 13.12 Premature Write: Overwriting uncommitted values Transaction T: a.setBalance(105) a.setBalance(105) $100 $105 a.setBalance(110) $110 Transaction U: a.setBalance(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 Ts write. 105 is the before image of Us 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.
Recover problem with 2PL

1. 2. 3. 4. 5. X-lock(X) A1 <- Read(X) A1 <- A1 * 10 Write(X, A1) Unlock(X)
1. 2. 3. 4. 5. 6.
X-lock(X) A2 <- Read(X) A2 <- A2 + 1 Write(X, A2) Unlock(X) 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 Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
Addison-Wesley Publishers 2005
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.
Strict two-phase Locking Protocol
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. Instructors Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 4
Addison-Wesley Publishers 2005
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

Figure 13.17 continued
public synchronized void release(TransID trans ){ holders.removeElement(trans); // set locktype to none notifyAll(); } }
// remove this holder
Deadlocks
Figure 13.19 Deadlock with write locks
Transaction Operations a.deposit(100); b.withdraw(100)
T Locks write lock A
Transaction U Operations Locks
b.deposit(200) waits for Us lock on B
write lock B
a.withdraw(200);
waits for T s lock on A
Figure 13.20 The wait-for graph for Figure 13.19
Held by
A T U T B
Waits for
Waits for
Held by
Figure 13.21 A cycle in a wait-for graph
U T
Figure 13.22 Another wait-for graph
V T U
Held by Held by
W Held by B
U
Held by
Waits for
T and W then request write locks on object C and a deadlock arises. V is involved in two cycles.
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. Bankers algorithm. Order the objects in certain order. Acquiring the locks need to follow this certain order.
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
Figure 13.23 Resolution of the deadlock in Figure 15.19
Transaction T Operations a.deposit(100); b.withdraw(100) waits for Us lock on B (timeout elapses) Ts lock on A becomes vulnerable, unlock A, abort T Locks
Transaction U Operations Locks write lock B waits for Ts lock on A
write lock A
b.deposit(200) a.withdraw(200);
a.withdraw(200);
write locks A unlock A, B
Deadlocks..
Increasing concurrency in locking schemes
Two version locking

allows one transaction to write tentative versions of data items while other transactions read from the committed version of the same data item; read operations wait only if another transaction is currently committing the same data item Lock Compatibility
Locking granularity
Typically there will be many objects in a system

--a typical transaction will access only a few of them (and is unlikely to clash with other transactions)
Granularity of locking affects concurrency

--smaller amount locked higher concurrency
Increasing concurrency in locking schemes contd..,
Hierarchic locks:
at each level, the setting of a parent lock has the same effect as setting all the equivalent child locks
Hierarchic locks:
Each node in the hierarchy can be locked-giving the owner of the lock explicit access to the node and implicit access to its children. Before a child node is granted a read/write lock an intention to read/write lock is set on the parent node and its ancestors(if any) Intention lock is compatible with other I locks but conflicts with read and write locks according to the usual rules
Optimistic Concurrency Control
Drawbacks of locking
Overhead of lock maintenance Deadlocks-> timeout and deadlock detection is not ideal for interactive programs. Reduced concurrency

In most applications, likelihood of conflicting accesses by concurrent transactions is low Transactions proceed as though there are no conflicts
Transactions
64
Principle transaction proceeds without checking conflict with others and prior to commit, validates its change by checking to see if data items have changed by committed transactions each transaction has three phases * Read phase/working phase ** committed version of data items for read - read set ** tentative version of data items for write - write set *Validation phase ** starts with EndTransaction request ** validate its change by checking to see if data items have changed by other transactions ** if no conflicts, commit; otherwise, abort * Write phase/update phase ** make changes permanent
Validation of transactions
Working T1 T2 T3 Transaction being validated active Later active transactions
Validation
Update Earlier committed transactions
Tv
active
Transactions
66
Validation uses the read-write conflict rules to ensure that the scheduling of a particular transaction is serially equivalent wrt all other overlapping transactions i,e any other transactions that had not yet committed at the time this transaction started. Each transaction is assigned a transaction number when it enters the validation phase i.e when the client issues a closetransaction. If T validated successfully retain transno No releasedaborted/readonly Nos ascending order A T always finishes its working phase after all transactions with lower nos
Optimistic Concurrency Control: Serializability of transaction Tv with respect to transaction Ti
Validation
Backward Validation: checks the transaction undergoing validation with other preceding overlapping transactionsthose that entered the validation phase before it. Forward Validation: checks the transaction undergoing validation with other later transactions, which are still active.
Validation of Transactions
If read set of Tv intersects write set of Ti
StartTn be the biggest transaction number assigned to some other committed transaction at the time when transaction Tv started its working phase. finishTn be the biggest transaction number assigned at the time when Tv entered the validation phase.
Validation of transactions
Transactions
Validation of Transactions
If write set of Tv intersects read Set of Ti)
Comparing Backward and Forward Validation
Backward: abort the transaction being validated Forward: three options: * defer the validation until the conflicting (and active) transactions have finished * abort all the conflicting active transactions and commit the one being validated * abort the transaction being validated
Comparing Backward and Forward Validation (contd)
Backward: must retain the write sets of committed transactions that may conflict with active transactions Forward: must allow for new transactions to start during validation Backward: compare a possibly large read set against old write sets Forward: compare a small write set against the read sets of active transactions
Transactions
Concurrency control
Lost update problem
Inconsistent retrievals
Serial equivalence
dirty reads
Recoverabilit y of transactions Cascading aborts
Locks
Optimistic concurrency control Timestamp ordering
Premature writes
Strict execution of transactions Tentative versions
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 transactions request to write an object is valid only if that object was last read and written by earlier transactions. A transactions request to read an object is valid only if that object was last written by an earlier transaction. This rule assume that there is only one version of each object and restrict access to one transaction at a time.
Timestamp ordering
Timestamps may be assigned from the servers clock or a counter that is incremented whenever a timestamp value is issued. Each object has a write timestamp and a set of tentative versions, each of which has a write timestamp associated with it; and a set of read timestamps. The write timestamps of the committed object is earlier than that of any of its tentative versions, and the set of read timestamps can be represented by its maximum member.
Timestamp ordering
Whenever a transactions 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.
Timestamp ordering and implementation
Good ordering:
objects read and write timestamps will be older than current transaction if it wants to write an object objects write timestamps will be older than current transaction if it wants to read an object
Abort and restart transaction for improper ordering Each transaction is given a time stamp when started. There is a total order of active transactions. Operations are validated when performed: writing only if no later transaction has read or written reading only if no later transaction has written
Operation conflicts for timestamp ordering

Rule Tc 1. write 2. 3. write read Ti read write write
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. 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. Tc must not read an object that has been written by any Ti where Ti >Tc this requires that Tc > write timestamp of the committed object.
It means the request is submitted too late
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. .
Write operations and timestamps

(a) T3 write
T2 T2 T3 Time
(b) T3 write
T1 T1 T2 T2 T3 Time
Tentative Key:
Before
Before After
Ti Committed Ti
After
(c)
T3 write
T1 T4
(d) T3 write
T4 Transaction aborts
object produced by transaction Ti (with write timestamp Ti) T1<T2<T3<T4
Before After
Before After
T1
T3
T4 Time
T4 Time
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
If a tentative version with write timestamp Tc already exists, the write operation is addressed to it, otherwise a new tentative version is created and given write timestamp Tc. Any write that arrives too late is aborted=>a transaction with a later timestamp has already read or written the object
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
If transaction Tc has already written its own version of the object, this will be used
a read opeartion that arrives too early waits for the earlier transaction to complete. If earlier transaction commits then Tc will read from its committed version.if it aborts, then Tc will repeat the read rule(and select the previous version)-prevents dirty read a read operation that arrives too late is aborted-it is too late I,e a transaction with a later timestamp has already written the object.
Read operations and timestamps

(a) T3 read T2 Selected read proceeds (b) T3 read
Key:
T2
T4
read proceeds
Ti
Selected
Time
(d) T3 read
read waits
Time
Committed
Ti Tentative
(c) T3 read
T1 T2 Selected
T4
Transaction aborts Time
object produced by transaction Ti (with write timestamp Ti) T1 < T2 < T3 < T4
Time
Exercise
Timestamps and versions of objects T U A RTS WTS {} S openTransaction bal = b.getBalance() b.setBalance(bal*1.1) openTransaction bal = b.getBalance() B C
RTS WTS RTS WTS {} S {} S
a.withdraw(bal/10) commit
bal = b.getBalance() b.setBalance(bal*1.1) c.withdraw(bal/10)
S<T<U
Timestamps in transactions T and U
Timestamps and versions of objects T U A RTS WTS {} S openTransaction bal = b.getBalance() b.setBalance(bal*1.1) openTransaction bal = b.getBalance() wait for T B C
RTS WTS RTS WTS {} S {} S { T}
S, T
a.withdraw(bal/10) commit
bal = b.getBalance() b.setBalance(bal*1.1) c.withdraw(bal/10)
S, T
T
{U}
T
T, U S, U
S<T<U
Multiversion Timestamp Ordering
The server keeps old committed versions as well as tentative versions in its list of versions of data items. With the list, Read operations that arrive too late need not be rejected. A Read operation of a transaction is directed to the version with the largest write timestamp less than the transaction timestamp.
A Late Write Invalidating a Read
Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.
Comparison
Locks
Timestamps
"Attitude" pessimistic optimistic Order dynamic static Decision Benefiting more writes read-only Trans. than reads Conflict wait; may Resolution abort later abort immediately

Chapter 11 Trans Concur

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 11 Trans Concur

Uploaded by

Copyright:

Available Formats

Slides for Chapter 11: Transactions and Concurrency Control

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Transactions and Concurrency Control

Simple synchronization (without transactions):Banking Example

Figure 13.1 Operations of the Account interface

Simple Synchronization without Transactions:Atomic operations at the server

Enhancing Client Cooperation by Signaling

Figure 13.2 A clients banking transaction

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

Figure 13.3 Operations in Coordinator interface

Figure 13.4 Transaction life histories

Successful openTransaction operation operation

Aborted by client openTransaction operation operation server aborts transaction

Aborted by server openTransaction operation operation

operation ERROR reported to client

Recoverability from aborts

Lost update problem

Optimistic concurrency control

Strict execution of transactions

Concurrency Control: the lost update problem

Concurrency Control: The inconsistent retrievals problem

Transaction V: a.withdraw(100) b.deposit(100) a.withdraw(100); $100

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

a, b accounts start with 200 both.

A serially equivalent interleaving of T and U

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

balance = b.getBalance() b.setBalance(balance*1.1) a.withdraw(balance/10) $80

A serially equivalent interleaving of V and W

Transaction : V a.withdraw(100); b.deposit(100) a.withdraw(100); b.deposit(100) $100 $300

total = a.getBalance() total = total+b.getBalance() total = total+c.getBalance() ...

Read and write operation conflict rules

Operations of different Conflict transactions read read No

A non-serially equivalent interleaving of operations of transactions T and U

Transaction T : x = read(i) write(i, 10)

y = read(j) write(j, 30) z = read (i)

Recoverability from aborts: A dirty read when transaction T aborts

Transaction :U a.getBalance() a.setBalance(balance + 20)

Figure 13.13 Nested transactions

T : top-level transaction T1 = openSubTransaction T2 = openSubTransaction T1 :

Committing Nested Transactions

General organization of managers for handling transactions.

Schemes for Concurrency control

Optimistic concurrency control Time-stamp based concurrency control

Figure 13.14 Transactions T and U with exclusive locks

waits for Ts lock on B lock B

Two-Phase Locking (1)

Strict Two-Phase Locking (2)

Strict two-phase locking.

Use of locks in strict two-phase locking

Shared Lock and Exclusive lock

Lock-based protocol -- example

Example of schedule with locks

3. Unlock(X) 4. A1 <- A1* 1.01

T1 6. Write(X, A1) 7. Unlock(X) 8. .

Lock based protocols -- questions

Lock based protocol need for a protocol

2. A1 <- A1 k X-lock (X) Unlock(X) 3. Write(X, A1)

5. A2 <- A2 * 1.01 (Y) 6. Write(Y, A2) X-lock Unlock(Y)

Two-phase locking -- motivation

X-lock(X) Write(X, 100) Unlock(X) T1

Two-phase locking -- motivation

Ensure that T1 does not read/write anything that T2 read/write.