1 / 19

18.8 Concurrency Control by Timestamps

18.8 Concurrency Control by Timestamps. Dongyi Jia CS257 ID:116 Spring 2008. Agenda . Timestamps Physically Unrealizable Behaviors Problems With Dirty Data The Rules for Timestamp-Based Scheduling Multiversion Timestamps Timestamps and Locking . Timestamp TS (T).

luna
Download Presentation

18.8 Concurrency Control by Timestamps

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. 18.8 Concurrency Control by Timestamps Dongyi Jia CS257 ID:116 Spring 2008

  2. Agenda • Timestamps • Physically Unrealizable Behaviors • Problems With Dirty Data • The Rules for Timestamp-Based Scheduling • Multiversion Timestamps • Timestamps and Locking

  3. Timestamp TS(T) • Scheduler assign each transaction T a unique number, it’s timestampTS(T). • The timestamp ordering protocol ensures that any conflicting read and write operations are executed in timestamp order.

  4. Timestamp TS(T) Each transaction is issued a timestamp when it enters the system. If an old transaction T1 has timestamp TS(T1), a new transaction T2 is assigned time-stamp TS(T2) such that TS(T1) <TS(T2).

  5. Timestamp TS(T) Two approaches to generate Timestamps: 1. Use the value of system, clock as the timestamp; that is, a transaction’s timestamp is equal to the value of the clock when the transaction enters the system. 2. Use a logical counter that is incremented after a new timestamp has been assigned; that is, a transaction’s is equal to the value of the counter when the transaction enters the system.

  6. Implementation of Timestamp-Based Protocols • we associate with each database element X two timestamp values and an additional bit: • RT(X): highest timestamp of a transaction that has read X. • WT(X): highest timestamp of a transaction that has written X. • C(X): commit bit for X, which is ture if and only if most recent transaction to wirte X has already committed.

  7. Implementation of Timestamp-Based Protocols • Purpose of this bit is to avoid a situation where one transactions T reads data written by another transaction U, and U then aborts. ---”dirty read” • These time stamps areupdated whenever a new Read(X) or Write(X) instruction is executed.

  8. U writes X T reads X T start U start Physically Unrealizable Behaviors • Read to late:a transaction U that started after transaction T, but wrote a value for X before T reads X. Figure: Transaction T tries to read too later

  9. U reads X T writes X T start U start Figure: Transaction T tries to write too late Physically Unrealizable Behaviors • Write too late:a transaction U that started after T, but read X before T got a chance to write X.

  10. U writes X T reads X U start T start U aborts T could perform a dirty read if it reads X when shown Problems with Dirty Data • Dirty Read: It is possible that after T reads the value of X written by U, transaction U will abort.

  11. U writes X T writes X T start U start T commits U aborts Figure: A write is cancelled because of a write with a later timestamp, but the writer then aborts Problems with Dirty Data • Thomas Write Rule Write can be skipped when a write with a later write-time is already in place.

  12. Problems with Dirty Data • A simple policy When a transaction T writes a database element X, the write is “tentative” and maybe undone if T aborts. The commit bit C(X) is set to false, and the scheduler makes a copy of the old value of X and its previous WT(X).

  13. The Rules of Timestamp-Based Scheduling Four Classes • the scheduler receives a request RT(X) • the scheduler receives a request WT(X) • the scheduler receives a request to commit T • the scheduler receives a request to abort T or decides to rollback T

  14. The Rules of Timestamp-Based Scheduling(1) • Scheduler receives a request RT(X) (a) If TS(T)>=WT(X), the read is physically realizable. i. If C(X) is true, grant the request. ii. If C(X) is false, delay T until C(X) becomes true or the transaction that wrote X aborts. (b) If TS(T)<WT(X), the read is physically unrealizable, abort T and restart it with a new, larger timestamp.

  15. The Rules of Timestamp-Based Scheduling(2) • Scheduler receives a request WT(X) (a) If TS(T)>=RT(X) and TS(T)>=WT(X), the write is physically realizable and must be performed. i. Write the new value for X ii.Set WT(X):=TS(T), and iii. Set C(X):= false.

  16. The Rules of Timestamp-Based Scheduling(2) • (b) If TS(T)>=RT(X), but TS(T)<WT(X), then the write is physically realizable, but there is already a later value in X. i. If C(X) is true, then the previous writers of X is committed, and ignore the write by T. ii. If C(X) is false, we must delay T. (c) If TS(T)<=RT(X), the write is physically unrealizable, and T must be rolled back.

  17. The Rules of Timestamp-Based Scheduling(3&4) • The scheduler receives a request to commit T. It must find all the database elements X written by T, and set C(X):= true. • The scheduler receives a request to abort T or decides to rollback T. Any transaction that was waiting on an element X that T wrote must repeat its attempt to read or write, and see whether the action is now legal after the aborted transaction’s writes are cancelled.

  18. Multiversion Timestamps • Multiversion schemes keep old versions of data item to increase concurrency. • Multiversion Timestamp Ordering • Multiversion Two-Phase Locking • Each successful write results in the creation of a new version of the data item written. • Use timestamps to label versions. • When a read(X) operation is issued, select an appropriate version of X based on the timestamp of the transaction, and return the value of the selected version. • reads never have to wait as an appropriate version is returned immediately.

  19. Timestamps and Locking • Generally, timestamping is superior than locking in next situations 1.Most transactions are read-only. 2.It is rare that concurrent transaction will try to read and write the same element. • In high-conflict situation, locking performs better than timestamps

More Related