databases concurrency control examples

Concurrency control examples

Mohammad DashtiYannis Klonatos

Aleksandar VitorovicEPFL

Concurrency control examples

Serializability Locking protocols Non-locking Protocols

Overview Optimistic Timestamp Multiversion

Serializability

All Conflict serializable programs are view serializable. But not the other way around

A schedule is serializable if it leaves the state of the DB the same as if the TXs were executed serially (serial schedule)

– T1: W(A) T2:R(A) T1:W(A) not serializableTip: start from the outside first: if a schedule is NOT

serializable, then it is neither view nor conflict serializable.

Serializable

View Serializable

Conflict serializable

Precedence Graph

The precedence graph for a schedule S contains: A node for each committed transaction in S An arc from Ti to Tj if an action of Ti precedes and conflicts with one of

Tj's actions. Two or more actions are said to be in conflict if:

– The actions belong to different transactions.

– At least one of the actions is a write operation.

– The actions access the same object (read or write).

A schedule is conflict-serializable if its precedence graph is acyclic

A schedule is view-serializable if it is view equivalent to a serial schedule

Serializability: Rules of thumb

Serializability: View equivalenceDatabase contains initial values (before any

write operation of ANY transaction in the schedule)

Some transaction will write the final value of a variable A in the schedule

Schedules S1 and S2 are view equivalent if: If Ti reads the initial value of A in S1, then Ti also

reads the initial value of A in S2 Otherwise, if Ti reads value of A written by Tj in

S1, then Ti also reads value of A written by Tj in S2 If Ti writes final value of A in S1, then Ti also writes

final value of A in S2

Serializability

• Is the following schedule conflict serializable?

No, Both contain cycles in the precedence graph.

Serializability

• Is the following schedule view serializable?

Yes.

No, either the first or third condition is not satisfied.

Locking protocols

Strict 2PL? No: all locks are held until commit.

2PL? Yes: T1 releases all locks right after R(B).

Non-locking protocols overview

The implicit cost of blocking/locking is replaced by work wasted by restarted transactions

Idea: restarting transactions is a rarely occuring event

Sets of transactions dealing with an objectMaintaining versions

Optimistic concurrency control protocol

Three phases:– READ: Xacts read from the database, but make

changes to private copies of objects. – VALIDATE: Check for conflicts. – WRITE: Make local copies of changes

Timestamps are assignedat the end of the READ phaseby order of arrival at that point

VALIDATION starts right after the last R/WWRITE phase take place on commit

Optimistic concurrency control protocol example 1

No, T2 will acquire a smaller TS number, so writeSet(T2) and readSet(T1) conflicts on A.T1 will abort and restart.Answer is YES if T1 begins first.


No, WriteSet(T1) and WriteSet(T2) conflicts.T2 will abort and restart.Change of Commit order will not help.Serializable: yes / Conflict & view serializable: yes.


Yes, executed without aborting, T2 has not written backits value yet, but actual execution order is:

Timestamp protocolAssigns Timestamp at the beginning of TxEach object has a RTS and a WTS

– Acquired from Transaction TSConflicts

– If actions are done in order different from TS order– If aborted, assigns a larger TS

Thomas write ruleWrite from T1 is ignored,

so that write from commited transaction T2 may persistA Serializable schedule that is not Conflict Serializable

is converted to Conflict Serializable scheduleThe write operation of the less recent transcation is

ignored

Multi-Version Timestamp Ordering (MVTO) protocol

Assigns Timestamp at the beginning of TxLet writers make a “new” copy

while readers use an appropriate “old” copyReaders are always allowed to proceed.

– But may be blocked until writer commits.

Multi-Version Timestamp Ordering (MVTO) protocol (cont.)

a unique timestamp TS(Ti) at the beginning of transaction Ti

R(A) in transaction Ti is mapped to R(Ak) where Ak is the version with the largest timestamp ≤ TS(Ti)

W(A) in transaction Ti is:

rejected if there is k s.t. R(Ak) in transaction Tj has property

TS(Tk) ≤ TS(Ti) < TS(Tj)

To check this condition, every object also has an associated RTS

when a xAct reads the object, the RTS is set to the max of the current RTS and the reader’s TS

If Ti wants to W(A) and TS(Ti) < RTS(A), Ti is aborted

otherwise, mapped into W(Ai)

Multi-Version Timestamp Ordering (MVTO) protocol (cont.)

Commit for transaction Ti is:

delayed until successful Commit for all transactions Tj that have written versions read by Ti

aborted, if any Tj (have written versions read by Ti) is aborted

Multiversion protocol example 1• Timestamp• No (violation of T1 in second read)

• Multiversion• Yes (local copies)

This schedule will be executed as:

Multiversion protocol example 2

Timestamp with Thomas Write rule Yes

Multiversion with Thomas Write Rule Yes

assume W(A) will not change RTS


No, R(A) in T2 is not aware of future W(A) in T1.T1 will detect inconsistency upon W(A) and restart with a higher TS. Serializable: yes.

No, the same story. Serializable: no.


TS(T1) < RTS(A) T1 is aborted T2 is aborted, as it readV1 written by T1

Yet another example

Tip: First ''Cleanup'' Reads and Writes that do not affect consistency

Not serializable (T2 and T3) → Not conflict serializable and not view serializable

Not allowed under:– 2PL and strict 2PL because of Y in T2– Timestamp (Timestamp of T2 is 2 and is less than

WTS(Y)=3, as written by T3)But, allowed under: Multiversion and Optimistic

databases concurrency control examples

Documents