Concurrency Control (2)

1. Concurrency Control (2)

2. So far… • Concurrency control through Locking Disadvantages of Locking • Overhead of locking and unlocking • Deadlocks cause delays (before aborts) • Strict 2P locking reduces concurrency Alternative: eliminate locks!

3. Optimistic Concurrency Control • Rationale: In most applications, the likelihood of two transactions accessing the same object is low. • High-level description: Transactions are allowed to proceed until the closeTransaction request is issued, at which time concurrency conflict is checked. In case of conflict, some transaction is aborted. • Each transaction has three phases: working phase, validation phase, and update phase.

4. Optimistic Concurrency Control • Each transaction has a tentative version of each object that it updates. The version is a copy of the most recently committed version of the object. • The first read accesses the committed version, subsequent reads are from the tentative version • All writes are to the tentative version

5. Optimistic Concurrency Control (2) • Working phase • Each transaction keeps two records: • A read set: contains the objects read by the transaction. • A write set: contains the objects written by the transaction. • Validation phase • When the closeTransaction request is received, the transaction is validated to see if its operations conflict with those of other transactions. • Update phase • If a transaction is validated, all of the changes recorded in its tentative versions are made permanent. • Commit=Validation+Update • Trans. aborts can happen only at the commit point (due to conflicts) never before operations

6. Tv Ti Rule write read 1. Ti must not read objects written by Tv read write 2. Tv must not read objects written by Ti write write 3. Ti must not write objects written by Tv and Tv must not write objects written by Ti Validation of Transaction • Each transaction is assigned a transaction number, T, when it receives closeTransaction. • A transaction with Ti always precedes a transaction with Tv if i < v. • For a transaction Tv to be serializable w.r.t. an overlapping transaction Ti we can define these (conservative) rules:

7. Working Validation Update T 1 Earlier committed transactions T 2 T 3 Transaction T being validated v active 1 Later active active 2 transactions Validation of Transactions

8. Validation of Transactions Tv Ti Rule write read 1. Ti must not read objects written by Tv read write 2. Tv must not read objects written by Ti write write 3. Ti must not write objects written by Tv and Tv must not write objects written by Ti 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;} Only one transaction may be in the validation and update phase. 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;} startTn is latest committed trans. when Tvt starts W.P., finishTn be latest committed when Tv enters V.P.

9. Transaction Aborts • When a backward validation fails, have to abort this transaction • When a forward validation fails, have several choices • Abort all conflicting transactions and commit this one • Abort this transaction (simple but wasteful if conflicting trans. abort in future) • Defer the validation until conflicting trans. have finished (but no guarantee it will ever succeed) • An aborted trans. may be restarted, but may abort each time  Starvation: failure of a trans. to ever commit

10. Timestamp Ordering • Instead of prevention of inconsistency by transaction manager (locks) we can allow transactions to execute, but cause them to abort if conflict is found during execution. • Trans. aborts can happen only before operations, never at the commit point (due to conflicts) • With single versions of objects: Each transaction is assigned a unique timestamp value when it starts. The timestamp defines its position in the time sequence of transactions. • A transaction’s “write” request is valid only if the object has been “read”and “written” by earlier (timestamp) transactions. • A transaction’s “read” request is valid only if the object has been “written” by earlier trans. • Trans. with invalid operations are aborted • This can never cause deadlocks (why?)

11. Timestamp Ordering • Each object has • A write timestamp (of the committed version) • A set of tentative versions (per transaction). Each version has • A write timestamp • A read timestamp (represented by the maximum value of the set). • Write TS of committed object is earlier than that of tentative versions. • Read TS of committed object is same as max of read TS’s • Whenever a transaction’s write operation is accepted, the server creates a new tentative version with write timestamp set to the transaction timestamp. • A transaction’s read operation is directed to the version with the maximum write timestamp less than the transaction timestamp. • The transaction’s TS is added to the list of the object’s read TS’s • When a transaction commits, values of the tentative versions become TS’s of the corresponding objects

12. Operation Conflicts for Timestamp Ordering Each read/write operation of a transaction is checked to see whether it conforms to the following rules. The transaction that has done some previous operation Tc=current 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. Ti > Tc 2. write write Tc must not write an object that has been written by any Ti where this requires that Tc > write timestamp of the committed object. Ti > Tc 3. read write Tc must not read an object that has been written by any Ti where this requires that Tc > write timestamp of the committed object.

13. When to accept a Write Rules 1 & 2: 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

14. (b) T3 write (a) T3 write T Key: T T Before Before 2 T 1 2 i Committed T T After After T T T 2 3 1 2 3 T i Time Time Tentative object produced by transaction Ti (c) T3 write (d) T3 write (with write timestamp Ti) Transaction T T T1<T2<T3<T4 T aborts 1 4 4 Before Before After After T T T T 1 3 4 4 Time Time Write Operations and Timestamps (write-write rule 2 only)

15. Timestamp Ordering Read Rule Rule 3: 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

16. (a) T3 read Key: read read T T T 2 4 2 proceeds proceeds T i Committed Selected Selected Time Time T i (d) T3 read (c) T3 read Tentative Transaction object produced by transaction Ti (with write timestamp Ti) T1 < T2 < T3 < T4 read waits T T T 4 aborts 1 2 Selected Time Time Read Operations and Timestamps (b) T3 read