1 / 7

Timestamps in Locking Protocols

Timestamps in Locking Protocols. Timestamps: used to avoid deadlock. each transaction has a single timestamp. timestamps are used to resolve conflicts between transactions. Possible Actions: wait: defer until conflicting transaction completes/aborts restart:

maili
Download Presentation

Timestamps in Locking Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Timestamps in Locking Protocols • Timestamps: • used to avoid deadlock. • each transaction has a single timestamp. • timestamps are used to resolve conflicts between transactions. • Possible Actions: • wait: defer until conflicting transaction completes/aborts • restart: • die - begin again but with original timestamp • wound - attempt to cause the conflicting transaction to die and continue when the conflicting transaction completes / aborts • Two algorithms: • wait-die: non-preemptive; a transaction finding a conflict waits • if it is older and dies if it is younger. • wound-wait: preemptive; a transaction finding a conflict wounds • if it is older and waits if it is younger CS 5204 Spring 99

  2. object R-ts W-ts Basic Timestamp Ordering (BTO) read <object,TS> if TS<W-ts then reject/abort else R-ts = max{R-ts,TS} write<object, val, TS> if TS <R-ts or TS <W-ts then reject/abort else W-ts = TS Thomas Write Rule: do not abort conflicting writes, simply ignore them. CS 5204 Spring 99

  3. Multiversion Timestamp Ordering read history R-ts1, R-ts2, ….., R-tsm Object versions <W-ts1, v1>, <W-ts2, v2>,….,<W-tsn, vn> read <object,TS> read vj where j = max{i|W-tsi<TS} add <TS> to read history write<object, val, TS> if (there is a k such that TS<R-tsk<W-tsj where j = min {i|TS<W-tsi}) then reject operation else add <TS, vl> to versions CS 5204 Spring 99

  4. Conservative Timestamp Ordering • Each Data Manager maintains: • a read queue (RQi) • a write queue (WQi) • for each Transaction Manger, TMi • Let: TS(Qi) denote the timestamp of the first operation in Qi (other Data Mangers) TM1 RQ1 WQ1 Scheduler DMk RQ2 TM2 WQ2 . . . . . TMN RQN WQN CS 5204 Spring 99

  5. Conservative Timestamp Ordering Let: TS(Qi) denote the timestamp of the first operation in Qi read <object,TS> if (non-empty(WQi) and TS(WQi) > TS for i = 1 ….N) then execute the read operation else add the read operation to RQi write<object, val, TS> if (non-empty (RQi) and non-empty (WQi) and TS(RQi) > TS for i = 1….N) then execute the write operation else add the write operation to WQi CS 5204 Spring 99

  6. Optimistic Algorithms (Kung-Robinson) • Each transaction, T, has three phases: • read phase • read from database and write to temporary storage (log) • validation phase • If (T does not conflict with any other executing transaction) • then • assign the transaction a unique (monotonically increasing) sequence number and perform the write phase • else abort T • write phase • write log to database CS 5204 Spring 99

  7. Optimistic Algorithms (Kung-Robinson) • Let: • ts be the highest sequence number at the start of T • tf be the highest sequence number at the beginning of T’s validation phase • validation algorithm: • valid = true; • for t = ts + 1 to tf do • if (writeset[t] intersect readset[T] != ) • then valid = false; • if (valid) • then • do write phase; • increment counter; • assign T a sequence number; CS 5204 Spring 99

More Related