SEMINAR REPORT ON

TIMESTAMPING AND OPTIMISTIC CONCURRENCY CONTROL

SUBMITTED BY Kamalpreet Kaur

CONCURRENCY CONTROL: Process of managing simultaneous execution of transactions in a shared database, to ensure the serializability of transactions, is known as concurrency control. Purpose of Concurrency Control 1. To enforce Isolation (through mutual exclusion) among conflicting transactions. 2. To preserve database consistency through consistency preserving execution of transactions. 3. To resolve read-write and write-write conflicts. Example: In concurrent execution environment if T1 conflicts with T2 over a data item A, then the existing concurrency control decides if T1 or T2 should get the A and if the other transaction is rolled-back or waits. Locking: Locking is pessimistic because it assumes that conflicts will happen. The concept of locking data items is one of the main techniques used for controlling the concurrent execution of transactions. A lock is a variable associated with a data item in the database. Generally there is a lock for each data item in the database. A lock describes the status of the data item with respect to possible operations that can be applied to that item. It is used for synchronising the access by concurrent transactions to the database items. A transaction locks an object before using it When an object is locked by another transaction, the requesting transaction must wait

Disadvantages of locking: Lock management overhead. Deadlock detection/resolution. Concurrency is significantly lowered, when congested nodes are locked. To allow a transaction to abort itself when mistakes occur, locks cant be released until the end of transaction, thus currency is significantly lowered (Most Important) Conflicts are rare. (We might get better performance by not locking, and instead checking for conflicts at commit time.)

Timestamp based concurrency control algorithm Timestamp A monotonically increasing variable (integer) indicating the age of an operation or a transaction. A larger timestamp value indicates a more recent event or operation. Timestamp based algorithm uses timestamp to serialize the execution of concurrent transactions. Basic Timestamp Ordering 1. Transaction T issues a write_item(X) operation: a. If read_TS(X) > TS(T) or if write_TS(X) > TS(T), then an younger transaction has already read the data item so abort and roll-back T and reject the operation. b. If the condition in part (a) does not exist, then execute write_item(X) of T and set write_TS(X) to TS(T). 2. Transaction T issues a read_item(X) operation:

a. If write_TS(X) > TS(T), then an younger transaction has already written to the data item so abort and roll-back T and reject the operation. b. If write_TS(X) TS(T), then execute read_item(X) of T and set read_TS(X) to the larger of TS(T) and the current read_TS(X). Strict Timestamp Ordering 1. Transaction T issues a write_item(X) operation: a. If TS(T) > read_TS(X), then delay T until the transaction T that wrote or read X has terminated (committed or aborted). 2. Transaction T issues a read_item(X) operation: a. If TS(T) > write_TS(X), then delay T until the transaction T that wrote or read X has terminated (committed or aborted). Thomass Write Rule 1. If read_TS(X) > TS(T) then abort and roll-back T and reject the operation. 2. If write_TS(X) > TS(T), then just ignore the write operation and continue execution. This is because the most recent writes counts in case of two consecutive writes. 3. If the conditions given in 1 and 2 above do not occur, then execute write_item(X) of T and set write_TS(X) to TS(T).

Validation (Optimistic) Concurrency Control Schemes In this technique only at the time of commit serializability is checked and transactions are aborted in case of non-serializable schedules. Optimistic Concurrency Control assumes that conflicts between transactions are rare. Does not require locking Transaction executed without restrictions Check for conflicts just before commit

(Terminology used) ReadSet(Ti): Set of objects read by Transaction Ti. WriteSet(Ti): Set of objects modified by Transaction Ti. Phases for Optimistic Concurrency Control 1. Read Phase 2. Validation Phase 3. Write Phase Read Phase No global writes take place Whenever the first write to a given object is requested, a copy is made, and all subsequent writes are directed to the copy. When the transaction completes, it requests its validation and write phases.

Validation Phase Checks are performed to ensure serializibility is not violated if the transaction updates are applied to the database. For read only validation consists of checks to ensure that the values read are the current values for the corresponding data items. If not interference has occurred, and the transaction is backed up and restarted. For a transaction that has updates, validation consists of determining whether the current transaction leaves the database in a consistent state, with serializibility maintained. If not, transaction is backed up and restarted. The scheduling of transactions is done by assigning transaction numbers to communication Each Transaction Ti is explicitly assigned a unique integer transaction number t(i) There must exist a serially equivalent schedule in which transaction Ti comes before transaction Tj whenever t(i) < t(j). To guarantee these numbering criteria one of the following three conditions must hold: a) Ti completes its write phase before Tj starts its read phase. b) The write set of Ti does not intersect the read set of Tj, and Ti complete its write phase before Tj starts its write phase. c) The write set of Ti does not intersect the read set or write set of Tj , and Ti completes its read phase before Tj complete its read phase.

Condition 1

Condition 1 states that Ti actually completes before Tj starts, i.e they execute completely in serial order Condition 2 Condition 2 states that the writes of Ti do not affect the read phase of Tj, and that Ti finishes writing before Tj starts writing. WS(Ti) disjoint from RS(Tj) Ti does not overwrite Tj Tj does not read any dirty data since Tj read data when Ti is still modifying it. Condition 3 Condition 3 is similar to Condition 2 but does not require that Ti finish writing before Tj starts writing; it simply requires that Ti does not affect the read phase or the write phase of Tj WS(Ti) disjoint from RS(Tj)

This condition allows Ti and Tj to write objects at the same time, but there is no overlapping for the sets written by these two transactions. WS(Ti) disjoint from WS(Tj).

Write Phase If the validation fails, the transaction will be backed up and started again as a new transaction If validation succeeds, then the transaction enters the write phase where locally written data are made global. Assigning Transaction Numbers

Transactions numbers should be assigned in order, since if Ti completes before Tj starts Ti < Tj.

Solution: Maintain a global counter, when transaction number is needed increment the counter and return the value. Transaction number must be assigned somewhere before validation, since validation require knowledge of the transaction number for the transaction being validated. Transaction numbers can be assigned at the beginning of the read phase. But this is not optimistic. Therefore these are usually assigned at the end of read phase