1 Module 4 Isolation Concepts COP 6730. 2 System State The system state consists of objects related in certain ways. These relationships are best thought

1

Module 4

Isolation Concepts

COP 6730

2

System State• The system state consists of objects

related in certain ways. These relationships are best thought of as invariants about the objects.

Examples:

– Account balances must be positive– All managers must be employers and so

must appear in the EMPLOYEE table

• The system state is said to be consistent if it satisfies all these invariants.

3

Appearance of Isolation (1)

Often, state must be made temporarily inconsistent while it is being transformed (by a transaction) to a new, consistent state.

Concurrent transaction execution must be controlled so that correct programs do not malfunction.

System try to control concurrency by providing the appearance of isolation (e.g., using locking).

4

Appearance of Isolation (2)

Employee

Manager

Transaction 1

Transaction 2

Transaction 3

Delete an employee

Appearance of isolation

5

Dependency Model of Isolation

The set of transactions {Ti} can run in parallel with no concurrency anomalies if their outputs are disjoint from one another’s inputs and outputs, i.e.,

Oi (Ij Oj) = for all i j

Ii Set of objects read by transaction Ti (it’s input)

Oi Set of objects written by Ti (it’s output){Ti

}Set of concurrent transactions

6

Cannot help in this caseEmployee

ManagerTransaction

1

Transaction 2

Transaction 3

I am corrupting the data


The ACID property assumes that the transaction knows what it is doing to its data (i.e., program is correct)

If a transaction runs in isolation, it will correctly transform the system state.

7

Static Allocation - Early Systems

• The transaction scheduler compares the new transaction’s needs to all the running transactions.

• If there was a conflict, initiation of the new transaction is delayed until the conflicting transactions has completed.

Problem: It is difficult to determine the inputs and outputs of a transaction before it runs.

Example: Since a banking transaction potentially updates any record of the Account table, static allocation would probably reserve the entire table.

→ Result in serial execution of the transactions

8

Dynamic Allocation• Each transaction is viewed as a

sequence of actions (rather then as an input-output set.)

• When an action accesses a particular object, the object is dynamically allocated to that transaction.

Advantage:

Allocation at action level → more concurrency

9

More Concurrency

Employee

Manager

Transaction 1

Transaction 2

Transaction 3

Delete an employee


I can proceed

I am blocked

10

Versions of Objects•Transactions are sequences of actions

operating on objects.

•Objects go through a sequence of versions as they are written by these actions:

– Nothing ever changes; rather, new versions of objects are created.

T1 T2<o,1>

<o,1>

<o,2>

Read Write

Different versionsof object o

11

Transaction Dependency (1)

T1T2

<o,1>

<o,1>

<o,2>

Read Write

• If a transaction reads an object, the transaction depends on that object version

• If the transaction writes an object, the resulting object version depends on the writing transaction.

I depends on <0,1>

I depends on T2

Since T2 may overwrite the data T1 depends on, we have a read-write dependency between T1 and T2

12

Transaction Dependencies (1)

Note: Only write actions create versions and dependencies.

READ WRITEdependency

WRITE READ dependency

WRITE WRITEdependency

• If a transaction reads an object, the transaction depends on that object version

• If the transaction writes an object, the resulting object version depends on the writing transaction.

13

Dependency Graph

<o,2>

T3

WriteWrite “T3 →T9” is not in the dependency graph

14

Isolation TheoremsAny dependency graph without cycles implies an isolated execution of the transactions.

T1

T4

T2

T3

The transactions can be topologically sorted to make an equivalent execution history in which each transaction ran to completion before the next one began (i.e., isolated execution).

Example: T1, T2, T4, T3

T1

T4

T2

T3Equivalent

15

Three Bad Dependencies

• There is no topological order for this set of transactions

concurrency anomalies.

• Cycles take one of only three generic forms

Lost Update, Dirty Read, and Unrepeatable Read

T1

T2

T3

16

Lost Update

Lost update: caused by WRITE->WRITE dependency

T2 READ < 0, 1 >

T1 WRITE < 0, 2>

T2 WRITE < 0, 3 >

T1’s write is ignored by T2

Lost update !

17

Dirty Read

Dirty Read: caused by WRITE -> READ dependencies

T2 WRITE < 0, 2 >

T1 READ < 0, 2 >

T2 WRITE < 0, 3 >

Dirty readDirty read

– T1 reads an object previously written by T2, then

– T2 makes further changes to the object

– T1 is using an outdated version of the object

18

Unrepeatable Read

Unrepeatable Read: caused by READ -> WRITE dependencies

T1 READ < 0, 1 >

T2 WRITE < 0, 2 >

T1 READ < 0, 2 >

T1 reads an object twice:

• once before T2 updates it, and

• once after committed T2 has updated it.

• The first read is not repeatable

Unrepeatable readUnrepeatable read

A Cycle in all Three Forms

19

Lost update !

Lost update !

Dirty readDirty read

Unrepeatable readUnrepeatable read

20

ISOLATION

Preventing the concurrency anomalies gives the effect of running transactions in isolation.

21

Dirty Outputs

Outputs of a transaction are said to be uncommitted or dirty, if the transaction has not yet issued COMMIT WORK.

22

Isolated Transactions

Transaction T is isolated from other transactions if:

1)T does not overwrite dirty data of other transactions.

2)T’s writes are neither read nor written by other transactions until COMMIT WORK

3)T does not read dirty data from other transactions.

4)Other transactions do not write any data read by T before T completes.

Preclude lost

update

Preclude lost update

Prevent dirty reads

Prevent dirty reads

Prevent unrepeatable

read

23

Properties of Isolated Transactions

• Each transaction reads a consistent input state.

• Any execution of the system is equivalent to some serial execution (no concurrency anomalies)

• None of the updates of committed transactions can be lost, and aborted transactions can be rerun.

24

NOTATIONS

s = < a, b, c > : a sequence

s || s : concatenation of two sequences

s[i] : the ith element of sequence s

< s[i] | predicate (s[i] ) > : a subsequence of s

The system state, S, consists of an infinite set of named objects, each with a value. S is denoted {< name, value >}

25

Actions on ObjectsThe system supports the following actions on these objects.

READ BEGIN

WRITE COMMIT

XLOCK (exclusive lock) ROLLBACK

SLOCK (share lock)

UNLOCK

To simplify the transaction model,

– BEGIN, COMMIT, and ROLLBACK are defined in terms of the other actions (next slide), so that

– only READ, WRITE, LOCK and UNLOCK actions remain.

26

COMMIT Example

Original Simplified

BEGIN SLOCK A XLOCK B READ A WRITE B COMMIT

SLOCK A XLOCK B READ A WRITE B UNLOCK A UNLOCK B

COMMIT action simply releases locks

27

ROLLBACK Example

Original Simplified

BEGIN SLOCK A READ A XLOCK B WRITE B ROLLBACK

SLOCK A READ A XLOCK B WRITE B WRITE B /* UNDO UNLOCK A UNLOCK B

ROLLBACK action must •first undo all changes to the objects the transaction

wrote, and •then issue the unlock statements

28

Well-Formed TransactionsA transaction is said to be well-formed if

– All its READ, WRITE, and UNLOCK actions are covered by locks (preceded by locking of the corresponding object), and

– Each lock action is eventually followed by a corresponding UNLOCK action.

READ and UNLOCK actions on O3 are not

covered by an SLOCK or XLOCK

WRITE action on O1 is not covered by an XLOCK

Not well-formed !

29

2-Phase Transactions

A transaction is defined as 2-phase if all its lock actions precede all its UNLOCK actions.

– Growing phase: acquiring locks

– Shrinking Phase: releasing locks

2-Phase transaction

time#

lock

s

Gro

win

g

Shrinking

30

Transaction Histories

• A history lists the order in which actions of a set of transactions were successfully completed.

Example:

–A transaction requests a lock at the beginning of the history but has to wait

–The lock is finally granted near the end of the history

–that lock request will appear near the end of the history

• A history preserves the order of the actions in each of the transactions.

Initial State

History

Trans. T2

Trans. T1

Trans. T2

Trans. T3

Trans. T1

Trans. T3

Another State

actionactionaction

actionactionaction

31

Serial History

• The simplest histories first run all the actions of one transaction, then run all the actions of another to completion, and so on.

The transactions are isolated

• Such one-transaction-at-a-time histories are called serial histories.

• serial histories have no concurrency-induced inconsistency and no transaction sees dirty data

32

Legal Histories• Locking constraints the

set of allowed histories.

• Histories that obey the locking constraints are called Legal.

This history cannot happen:T1 slock AT2 xlock AT2 write AT1 read A

33

Legal Histories - Examples

• Histories are not constructed, they are a byproduct of the system behavior.

• Locking systems only produce legal behavior.

T2 wouldbe made

to waituntil this

time

States of a Transaction

34

Active

Blocked

Block

Resume

Running

Begin

Aborted

Reject

Committed

Commit

Restart(sometime)

Scheduler

35

T1

T2

T3

T4

T5

actions inarriving order

next action

Activetransactions

Histories are not constructed, they are a byproduct of

the system behavior.

Histories are not constructed, they are a byproduct of

the system behavior.

Abort the transactions

Scheduler

Lock Compatibility

Table

Blocked Actions

serializable schedule

RejectedActions

Rejected Actions: Actions that violate the 2-phase and/or Well-formed rules

bad action

Legal history

An Analogy

36

An action of transaction

1


1


4


4


3


3


2


2

Scheduler

Scheduler

37

Version of an Object• < T, a, o >: a step of the history. It denotes

an action a by transaction T on object o.

• V(o, k): The version of an object o at step k of a history.

At step k of history H, object o has a version equal to the number of writes of that object before this step.

V(o, k) = |{< t, aj, o >H | j<k and aj = WRITE}|

Set size Action at Step j

38

Dependency Relation• Each history H for a set of transactions {Ti }

defines a ternary dependency relation DEP(H):

< T, < o, V(o,j) >, T > DEP(H)

if a1 is a WRITE and a2 is a WRITE, or a1 is a WRITE and a2 is a READ, or a1 is a READ and a2 is a WRITE.

where a1 and a2 are actions performed on the object o by T and T, respectively.

• This definition captures the WRITEWRITE, WRITEREAD, and READWRITE dependencies.

DEP(H): [SourceTrans, OID, ObjVersion, DestTrans]

39

Dependency Graph

• The dependency relation for a history defines a directed dependency graph:

– transactions are the nodes, and

– object versions label the edges.

•< T, < o, j >, T > DEP(H) the graph has an edge from node T to node T labeled by < o, j >

T1

T’

T

T2 <o,j >

40

Isolated Histories

• Two histories for the same set of transactions are equivalent if they have the same dependency relation, i.e., DEP(H) = DEP(H).

They have the same effect on the database

• A history is said to be isolated if it is equivalent to a serial history.

Equivalent Histories - Example

41

T3.1

T1.2

T1.1

T2.1

T3.2

T3.3

T2.3

T2.2

T4.1

T3.4

T3.5

T2.5

T2.4

T4.2

T1.3

T4.3

T4.4

T1.4

T4.5

T1.1

T2.1

T1.2

T1.4

T1.3

T2.2

T3.1

T2.3

T2.5

T2.4

T3.2

T4.1

T3.3

T3.5

T3.4

T4.2

T4.3

T4.5

T4.4

History H Serial history SH

T1

T2T3

T4

DEP(H) = DEP(SH)

• DEP(H) = DEP(SH) The corresponding transactions in H and

SH read the same input and compute the same output

H and SH are equivalent

• SH executes the transactions in isolation H also executes the transactions in

isolation

42

Dependencies in a History• The dependencies of a history define a time

order of the transactions. This ordering is denoted by the symbol “<<<.”

– T<<< T if there is a path in the dependency graph from transaction T to transaction T, i.e.,

T<<< T if <T, o, T> DEP(H), or /* direct */

T<<<HT and < T, o, T > DEP(H) /* indirect */

– All equivalent histories define the same ordering.

• Notations:

BEFORE(T) = {T | T<<<T}

AFTER(T) = {T | T<<<T}

T is called a wormhole transaction if

T BEFORE(T) AFTER(T)

T AB

Z

Y XT’

T BEFORE(T)

T AFTER(T)

43

WORMHOLES ARE NOT ISOLATED

• T<<<T<<<T indicates a cycle in the dependency graph.

• Since a dependency graph with cycles is not equivalent to any serial history, a history with wormholes is not isolated.

44

WORMHOLE TRANSACTIONS

No wormhole T3,T4,T5,T6 transactions are wormhole transactions No cycles! Cycles!

Note: Two transactions not related by <<< maybe arbitrarily scheduled with respect to each other, e.g., T2 and T4

45

Wormhole Theorem

A history is isolated if, and only if, it has no wormhole transactions.

46

Locking Theorems1. Locking theorem: If all transactions are well-formed

and two-phase, then any legal history will be isolated.

Analogy:

• Traffic lights provide a “safety” mechanism

• If all drivers are good citizen, traffic lights prevent accidents

2. Locking theorem (converse): If a transaction is not well-formed or is not two-phase, then it is possible to write another transaction such that the resulting pair is a wormhole.

Analogy: If there are bad drivers, then accidents can occur

47

Rollback Theorem

An update transaction that does an UNLOCK and then a ROLLBACK is not two-phase.

48

Wormhole Theorem: Proof

Wormhole Theorem: A history is isolated if, and only if, it has no wormhole transactions.

We need to prove two things:

1.History H is isolated no wormholes

(proof is by contradiction – next page)

2.H has no wormholes H is isolated

(proof is by induction)

49

Wormhole Theorem: Proof (cont’d)

1. History H is Isolation no wormholes (proof is by contradiction)

– Suppose H is an isolated history of {Ti | i = 1,.., n} H is equivalent to some serial history

SH = T7 || T4 || T9 || … || Tn

– Rename the corresponding transactions in H and SH to obtain the following transaction index pattern for SH:

SH = T1 || T2 || T3 || … || Tn (1)

– Suppose that H has wormhole (contradiction):

T <<< T <<< … Tj <<<H Ti <<<… <<< T <<< T, where i is the minimum transaction index in this wormhole.

– By the minimality of i, we must have Ti <<<SH Tj according to (1) Tj<<<SH Ti is impossible.

Tj<<<H Ti is not possible (because H and SH are equivalent)

H has no wormholes.

Not possible

50


2. H has no wormholes H is isolated: This proof is by induction on the number of transactions, n, that appear in the history, H.

(1) If n < 2, then any history is a serial history any history is isolated.

(2) Suppose the induction hypothesis is true for n - 1 transactions

i.e., “H has no wormholes H is isolated” is true for n-1 transactions

(3) Considering some history H of n transactions that has no wormholes, prove that H is isolated (see next page)

History H has no wormholes H is isolated

51

n transaction

s

History Ha

T

T’

T*

…

DEP(H)

No wormholes→ We can find a

transaction without outgoing edges


52

Remove T*

n transaction

s

History H

b

a

T

T’

T*

…

DEP(H)

T

T’

…DEP(H’)

withoutT*

Remove T*

c

n-1 transactios

History H’

This must be the dependency graph for H’


53

Remove T*

n transaction

s

History H

b

=

a

T

T’

T*

…

DEP(H)

T

T’

…DEP(H’)

withoutT*

DEP(SH’)without

T*

due to induction hypothesi

s

d

Remove T*

c

n-1 transactios

History H’

H’ has no wormhole→ H’ is isolated→ DEP(H’) = DEP(SH’)


54

+Remove

T*

n transaction

s

History H

b

=

a

T

T’

T*

…

DEP(H)

T*

T

T’

…DEP(H’)

withoutT*

DEP(SH’)without

T*


s

d

e1

Remove T*

c

n-1 transactios

History H’

T*

DEP(SH’) with T* added


55

+

=

Remove T*

n transaction

s

History H

b

=

a

T

T’

T*

…

DEP(H)

T*

T

T’

…DEP(H’)

withoutT*


s

d

e1

Remove T*

c

n-1 transactios

History H’

e2

due to Step d

Ξe3

T*

DEP(SH’) with T* added

T*

DEP(H’) with T*

Some DEP(SH)

=e5

e2, e3 & e5 → DEP(H) and DEP(SH) are equivalent

DEP(SH’)without

T*

due to Step c

56


(a) Pick a transaction T and construct the sequence

S = < T, T, … T* > such that T <<<H T <<<H … <<<H T*

Since H has no wormhole, S must be finite.

(b) Remove all actions due to T* from H to construct a history H’: H = < < Ti, a, o > H | Ti T* >

(c) Construct DEP(H’) by removing from DEP(H), T* & its incoming edges:

DEP (H) = { < T, < o, i >, T > DEP(H) | T T* }

(d) H has no wormholes H has no wormholes H is isolated ( due to induction hypothesis – page 50) H has an equivalent serial history SH’

(e) DEP(SH) can be constructed by adding T* and its incoming edges to DEP(SH’)

DEP(SH) = DEP(SH) { < T, < o, i >, T* > DEP(H) }

57


(e) DEP(SH) can be constructed by adding T* and its incoming edges to DEP(SH’)

DEP(SH) = DEP(SH) { < T, < o, i >, T* > DEP(H) }

= DEP (H) { < T, < o, i >, T* > DEP(H) }

/* DEP(SH’) = DEP(H’) due to Step (d)

= { < T, < o, i >, T > DEP(H) | T T* } { < T, < o, i >, T* > DEP(H) }

/* DEP(H’) = { < T, < o, i >, T > DEP(H) | T T* } due to Step (c)

= Adding T* and its incoming edges to the DEP(H) with T* and its incoming edges removed

= DEP(H). /* Thus, the induction step is proven.

58

Serializability Theorem

• The wormhole Theorem is the basic result from which all the others follow.

• The wormhole Theorem can be stated in many different ways.

Serializability Theorem: A history H is isolated if, and only if, <<<H implies a partial

order of the transactions (i.e., no cycles).

• An isolated history is also called a serializable schedule or a consistent schedule.

59


DEP(H) DEP(SH)

Same dependencygraph

60


If there had been a cycle, it would have produced dependency graph arrows pointing up in the serial history SH (back in time).Executing SH would violate a dependency in the original history HDEP(H) ≠ DEP(SH)H is not a serializable schedule

DEP(H) DEP(SH)

61


If there had been a cycle, it would have produced dependency graph arrows pointing up in the serial history SH (back in time).Executing SH would violate a dependency in the original history HDEP(H) ≠ DEP(SH)H is not a serializable schedule

DEP(H) DEP(SH)

62

Locking Theorem: Lemma

• SHRINK(T) the index of the first unlock

step of T in the history H.

• Lemma: Let T and T be two well-formed and 2-phase transactions of a legal history H.

T <<<direct T SHRINK(T) < SHRINK(T)

T→T’ is independency

graph

63

Locking Lemma - ProofLemma: Let T and T be two well-formed and 2-phase transactions of a legal history H.


T <<<direct T T’ waits for T on some lock

T’ cannot have this lock until after SHRINK(T)

T’ cannot release its first lock until after SHRINK(T)

SHRINK(T) < SHRINK(T’)

Obtainlock X Request

lock X

Releaselock X

SHRINK(T) SHRINK(T’) Time

Nu

mb

er

of

Lock

s

T T’

T ’ is blocked

Releaselock X

T <<< T’

T

T’ This occurs after

SHRINK(T)

64

Locking Lemma – Formal Proof

Lemma: Let T and T be two well-formed and 2-phase transactions of a legal history H.


T <<<direct T there are some steps i < j of H such that

H[i] = < T, a, o >, H[j] = < T, a, o >, and

a and a are conflicting actions.

H is legal H does not grant conflicting locks to two different transactions at the same time.

there must be a k1 and k2 such that i < k1 < k2 < j, H[k1] = < T, UNLOCK, o >, and H[k2] = < T’, LOCK, o >.

T and T are 2-phase SHRINK(T) k1 < k2 < SHRINK(T)

T

T’

65

Locking Theorem: ProofLocking Theorem: If all transactions are well-formed and two-phase, then any legal history will be isolated (locking correctly done provides the isolation).

This proof is by contradiction.

– Suppose that H is not isolated.Wormhole theorem there must be a sequence < T1,…, Tn > such that: T1 <<<direct T2 <<< direct … <<< direct Tn <<< direct T1

– Lemma SHRINK(T1) < SHRINK(T2) < … < SHRINK(T1)

– “SHRINK(T1) < SHRINK(T1)” is not possible ! H cannot have any wormhole.

66

Degenerate Transactions

A transaction is degenerate if it does any of the following:

– Useless lock: Locks something that it never reads or writes

– Orphan unlock: Unlocks something that it has not locked.

– Orphan lock: Ends without unlocking some of its locks (impossible if it ends with COMMIT or ROLLBACK).

67

Locking Theorem - Converse

Locking Theorem (converse): If a transaction is not well-formed or not two-phase, then it is possible to write another transaction such that the resulting pair has a legal but not isolated history (unless the transaction is degenerate).

Need to prove two things:

•Not well-formed legal but not isolated •Not two-phase legal but not isolated

68

Locking Theorem - Converse (Proof)

Not well-formed legal but not isolated – Suppose that transaction T is not well formed and not degenerate:

T = < <T[i] | i<k > || <T, ak, o> || <T[i] | i>k > >

– We can write a transaction T:T = < <T, XLOCK, o>, <T, WRITE, o>, <T, WRITE, o>, <T, UNLOCK, o> > T is 2-phase and well-formed.

– Consider the history:H = <T[i] | i<k > || < T[1], T[2], T[k], T[3], T[4] > || < T[i] | i > k > H is legal since no conflicting locks are granted on object o at any point of the history.

– H implies that <T, <o, j>, T> and <T, <o, j>, T> must be in DEP(H) for some j. T<<< T<<<T T is a wormhole. H is not isolated (Wormhole Theorem).

W WR

Not covered by lock

ak is a READ or WRITE that is not covered by a lock. READ case is proved here; WRITE case is similar

69

Locking Theorem (Converse): Proof (cont’d )

Not two-phase legal but not isolated

– Suppose flat transaction T is not two-phase: T = < < T, a1, o >, .., < T, aj, o1 >, .., < T, ak, o2 >, … >

UNLOCK SLOCK or XLOCK

– We can write a transaction T:T = < < T, XLOCK, o1 >, < T, XLOCK, o2 >, < T, WRITE, o1 >,

< T, WRITE, o2 >, < T, UNLOCK, o1 >, < T, UNLOCK, o2 > >

T is two-phase and well-formed.

– Consider the history: H = < T[i] | i j > || T || < T[i] | i > j > H is legal

< T, < o1, m >, T > and < T, < o2, n >, T > must be in DEP(H). T <<<H T <<<H T T is a wormhole in H. H is not an isolated history (according to the Wormhole Theorem).

A loop in dependency

graph

A loop in dependency

graph

Since T is not degenerate, it read/write 01 before the UNLOCK at Step j

Since T is not degenerate, it

read/write 02 after the UNLOCK at Step k

70

Locking Theorem• Locking Theorem:

“If every transaction is well-formed and two-phase, a history is isolated.”

Note: An isolated history does not imply that its transactions are well-formed and two-phase.

Example: A serial history is isolated even if its transactions are not well-formed or two-phase. (In fact, we don’t even need locking in this case).

• It would be nice if the Locking Theorem were stronger and read:

“A history is isolated if, and only if, every transaction is well-formed and two-phase.”

Program should be correct !

Rollback Theorem - ProofRollback Theorem: A transaction that does an UNLOCK of an XLOCK and then does a ROLLBACK is not well-formed and, consequently, is a potential wormhole (unless the transaction is degenerate).

<XLOCK o> … <UNLOCK o> <ROLLBACK>


<XLOCK o> <WRITE o> … <UNLOCK o> <ROLLBACK>

Since the transaction is not degenerate, it must

write o

73


<XLOCK o> <WRITE o> … <UNLOCK o> <ROLLBACK>

1) <XLOCK o> <WRITE o> … <UNLOCK o> <WRITE o>

The second WRITE is not covered by a lock the transaction is not well-formed the transaction is a potential wormhole.

UNDO - not covered by a

lock

UNDO is covered by a

lock

2) <XLOCK o> <WRITE o> … <UNLOCK o> <XLOCK o> <WRITE o>

The second WRITE is covered by a lock the transaction is not two phase the transaction is a potential wormhole.

IMPORTANT: XLOCK’s should be kept until the end

74

Rollback Theorem - Proof (2)

Rollback Theorem: A transaction that does an UNLOCK of an XLOCK and then does a ROLLBACK is not well-formed and, consequently, is a potential wormhole (unless the transaction is degenerate).

– T acquires XLOCK on object o & T is not degenerate

T write o

– The ROLLBACK action has to WRITE (UNDO) object o again.

– The second WRITE is not covered by a lock the transaction is not well-formed the transaction is a potential wormhole.

– It might be argued that the ROLLBACK should reacquire XLOCK on all such unlocked objects.However, that would violate the 2-phase restriction and, in doing do, introduce another potential wormhole.

75

Summary of the Isolation Theorems

• The implication of these theorems is that a transaction should:

1. Be well-formed: it should cover all actions with locks

2. Set XLOCK on any data it writes.

3. Be 2-phase: it should not release locks until it knows it needs no more locks.

4. Hold XLOCKs until COMMIT or ROLLBACK.

If these rules are followed, the execution history will give each transaction the illusion it is running in isolation.

• On the other hand, if any of the above rules are violated, then the transactions may have inconsistent inputs or outputs.

76

Isolation: In PracticeMost applications do not require true isolation. Implementers make compromise between correctness and performance.

– Typical SQL system default is to ignore READ WRITE dependencies

Cursor stabilityOne the cursor is advanced to the next item, another transaction can WRITE the last item (i.e., READ →WRITE) users must request true isolation as an option.

– Many systems also allow the option to ignore WRITE READ isolation.

Browse access

allows queries to scan the database without acquiring locks and without delaying other transactions.

These queries ignore XLOCK’s by other transactions

77

Degree of Isolation

• Degree 3: This is true isolation.– Lock protocol: two-phase and well-formed

• Degree 2: A 2° isolated transaction has no lost updates and no dirty reads.– Lock protocol: two-phase with respect to

XLOCKs and well-formed

– Common name: Cursor stabilityNot 2-phase w/r to read Ignore READ → WRITE Repeatable read is not guaranteed

78

Degree of Isolation(cont’d)

• Degree 1: A 1° isolated transaction has no lost updates.– Lock protocol: two-phase with respect to

XLOCKs and well-formed with respect to writes

– Common name: browse mode Read operations do not require locking Ignore “READ → WRITE” & “WRITE → READ”

• Degree 0: A 0° isolated transaction does not overwrite another transaction’s dirty data if the other transaction is 1° or greater.– Lock protocol: well-form with respect to write

– Common name: anarchy /* ignore all dependencies */

79

DEGREE OF ISOLATION

Degreeof

Isolation

Read Write

Ignored EffectWF 2P WF 2P

Degree 3 Yes Yes Yes Yes N/A

True isolation

Degree 2

(cursor stability

)

Yes No Yes Yes Read Writeunrepeatable

reads

Degree 1

(browse mode)

No No Yes YesRead Write

Write Read

unrepeatable reads

dirty reads

Degree 0

(anarchy)

No No Yes No

Read WriteWrite Read

Write Write

unrepeatable reads

dirty readslost updates

80

Knowing What They Are Doing

“Cursor stability” applications do not

repeat read operations anyway !

As long as applications know what they are doing, better performance can be achieved without causing anomalies

81

Mixing Isolation Levels

A 1 transaction’s inputs are 1 isolated

the transaction may get dirty reads.

such data may not satisfy the system inconsistency constraints.

If the transaction uses dirty reads to update the database, then other transactions will see inconsistent values and may malfunction.

such transaction systems assume that the 1 transaction knows what it is doing.

Example: Most systems reserve 1 isolation (browse mode) for read-only transactions.

82

SQL systems• The lower degrees of isolation allow

transactions to acquire fewer locks or to hold the locks for a shorter time.

• SQL systems implement a slightly better form of isolation than pure 2.

Pure 2: After reading the cursor, the SLOCK is immediately released

Cursor stability: To prevent lost updates, most SQL systems keep a shared lock on the record currently addressed by a cursor (see next page).

83

Cursor Stability Examples

Another transaction can update the balance at this time, and the update will be lost. Account

record islocked duringthis timeperiod

Accountrecord islocked duringthis timeperiod

Look up balance

“balance” value may be

stale

An SQL query is an atomic operation

84

Phantomsselect *from EMPwhere eyes = “blue” and hair = “red”;

• Technique 1: Locks all the individual records that satisfy the where clause (predicate)

Problem: What is to prevent someone else from inserting a new, blue eyed, red-haired EMP during the execution of the above query.

Name Eyes Hair

Andrew Blue Red

Casey Blue Red

Jane Blue Red

Kailee Blue Red

Justinserted

Firstmatch

Secondmatch

“Casey” is a phantom !

85

Phantoms(cont’d)

select *from EMPwhere eyes = “blue” and hair =

“red”;

• Technique 2: Locks the whole EMP table

Problem: significantly reduces concurrency (unacceptable)

86

Predicate LocksRather than locking an individual object, a predicate lock can specify a subset of the database to which the lock applies.

Example:

<t, slock, emp.eyes = “blue” emp.hair = “red”>

Transaction t requests slocks for all the emp tuples that satisfy this predicate.

Predicate lock is an elegant solution for phantoms.

87

Predicate Locks - Compatibility

<t, mode, p> and <t’, mode’, p’> are compatible if1. t = t’, or2. mode = mode’ = slock, or3. (p AND p’) = FALSE /* t and t’ access a different subset of the database */

Examples:

< t, slock, emp.eyes = “blue” emp.hair = “red” >

< t, xlock, emp.eyes = “blue” >

< t, slock, emp.eyes = “blue” >

< t, xlock, emp.eyes = “blue” >

compatible

compatible

incompatible

1

2

3

88

Predicate Locks: Scheduling

A predicate lock system can schedule transactions dynamically as follows:

– Each time a transaction requests a predicate lock, the system compares the lock request with the other granted and waiting predicated locks.

– If the lock request is compatible with all other requests,

• it is added to the granted set and granted immediately.

• Otherwise, it is marked as waiting and added to the waiting list.

89

Predicate Locks: Scheduling (cont’d )

• When a transaction ends, the waiting predicates in the waiting list are considered in turn.

– The scheduler grants each predicate that is compatible with the new granted group, and adds it to the granted set.

– When it encounters the end of the waiting list, or an incompatible predicate lock in the list, it stops and waits for the next lock or unlock request.

This scheme is very expensive not used in practice.

90

Granular Locks• Predicate locks (predicate comparisons)

are too expensive. Simplified predicate locks, called granular locks, are typically used in practice.

• In granular locking, the system picks a fixed set of predicates (in essence, to precompute the predicate locks):

– Each predicate is represented by a name, and

– the predicates are organized into a lock hierarchy (for compatibility check).

91

Granular Locks - Example

Example:

– A finest granularity lock:Sites = “Orlando” Files = “Phone” Records = “Steven”

– To lock all the data in Chicago (coarse grain)Sites = “Chicago”.

Chicago Los Angeles Orlando

Jerry

92

Implicit Locking

When a transaction sets a lock on a granule at a given level of the granularity, it is implicitly locking in the same mode all its descendants.

Example: when a lock is set on a relation, all tuples of this relation are locked in the same way.

93

Incompatible LocksIt is necessary to guarantee that

– after setting a basic lock (SLOCK, XLOCK) on a given vertex of the granularity hierarchy by a transaction T,

– no other transaction T obtains an incompatible lock on any of its predecessors.

Transaction T locksthe file Phone

Sometime later, T’ XLOCKs “Chicago”

(must be blocked) Chicago Los Angeles Orlando

JerryVerifying lock

compatibility can

be very expensive

1

2

94

Intent Lock Mode

There must be a way to prevent T from settingxlock on “Chicago”.

A solution: using Intention locks.– Setting an intention lock at a given level

implies basic locking at all lower levels.– The modes of intention locks depend directly

on the modes of the basic lock.

Transaction T locksthe file Phone

Sometime later, T’ XLOCKs “Chicago”

(must be blocked)Chicago Los Angeles Orlando

Jerry

95

Intention Locking - Example

Setting a record-granularity SLOCK on “Jerry” consists of the following sequence of lock requests.

LOCK “IN DATABASE” IN INTENT MODELOCK NODE = “Chicago” IN INTENT MODELOCK FILE = “PHONE” IN INTENT MODELOCK NAME = “Jerry” IN SHARED MODE

Intent mode represents the intention to set locks at a finer granularity.

INTENT

INTENT

INTENT

Chicago Los Angeles Orlando

Jerry

SHARED

96

Intention locks

• IX: Intent to set shared or exclusive locks at finer granularity.

• IS: Intent to set shared locks at finer granularity.

• SIX: A shared lock on a given granule with intent to set finer-granularity shared or exclusive locks.

97

Intention locks - Compatibility

“+”: compatible “-”: incompatible

Granted Mode

Request Mode None IS IX S SIX Updat

eX

IS + + + + + - -IX + + + - - - -S + + - + - - -

SIX + + - - - - -Update + - - + - - -

X + - - - - - -

We can block the lock request later if the IX actually has a

conflicting X lock in the lower level of the hierarchy

98



Granted Mode


eX

IS + + + + + - -IX + + + - - - -S + + - + - - -

SIX + + - - - - -Update + - - + - - -

X + - - - - - -

We cannot grant the IX request since nothing will

prevent it from having an X lock in the lower level of the

hierarchy, otherwise.

99



Granted Mode


eX

IS + + + + + - -IX + + + - - - -S + + - + - - -

SIX + + - - - - -Update + - - + - - -

X + - - - - - -

We cannot grant the SIX request because the IX

might have an X lock in the lower level of the

hierarchy

100



Granted Mode


eX

IS + + + + + - -IX + + + - - - -S + + - + - - -

SIX + + - - - - -Update + - - + - - -

X + - - - - - -

101

Common Deadlocks

A typical construct in programs is to read a record and rewrite some of its fields.

– If two different transactions both read an object at nearly the same time, then they both request it in exclusive mode. That creates a deadlock cycle.

T1 SLOCK AT2 SLOCK AT1 XLOCK AT2 XLOCK A

T1

T2

Wait-for GraphT1 is now blocked

T2 is now blocked

Wait-for Graph ≠ Dependency Graph

102

T1

T2

T3

T4

T5

Scheduler

Blocked Actions

actions inarriving order

next action

serializable schedule

Result in a wait-for graph

Result in a dependency graph

A cycle in the wait-for graph does not imply a non-serializable schedule

103

Common DeadlocksA typical construct in programs is to read a record and rewrite some of its fields.

– If two different transactions both read an object at nearly the same time, then they both request it in exclusive mode. That creates a deadlock cycle.

T1 SLOCK AT2 SLOCK AT1 XLOCK AT2 XLOCK A

– A study of system R showed that virtually all deadlocks in that system were of this form.

– A possible solution is to make shared locks incompatible - Reduce concurrency !

T1

T2

Wait-for Graph

104

Update LocksA better solution: use UPDATE lock mode.

– When an SQL cursor is declared with the clauseFor UPDATE, record locks acquired by the cursor are acquired in UPDATE mode.

– If the cursor updates the data

• then the update mode lock is converted to an XLOCK, which is held to transaction commit.

• else the update mode lock is downgraded to shared mode

– UPDATE is not compatible with a subsequent UPDATE request

Cursor acquired in UPDATE

mode

Update data

XLOCKmode

SLOCKmode

YesNo

Improve concurrency

105

Update locks - Compatibility

Granted Mode

Request Mode None IS IX S SIX

Update

X

IS + + + + + - -IX + + + - - - -S + + - + - - -

SIX + + - - - - -Update + - - + - - -

X + - - - - - -The compatibility matrix for update mode locks is asymmetric:• Update is compatible with share, but share is not compatible with

update• This allows the updater to read, but delays other transaction readers

and updaters, since the transaction is about to update

106

Update Lock Example

• A typical construct in programs is to read a record and rewrite some of its fields.

T1 UPDATE AT2 UPDATE A (T2 is blocked)T1 WRITE A (the update lock becomes XLOCK) …T1 COMMITT2 WRITE A (T2 is resumed, the update lock becomes XLOCK) … T2 COMMIT

• No deadlock in the above action sequence

T2

defe

rred

107

Granular Locking Protocol• Acquire locks from root to leaf

• Release locks from leaf to root.

• To acquire an S mode or IS mode lock on a non-root node, its predecessor must be held in IS mode or higher (one of {IS, IX, S, SIX, U, X})

• To acquire an X, U, SIX, or IX mode lock on a non-root node, its predecessor must be held in IX mode or higher (one of {IX, SIX, U, X})

108

Granular Locking Example

• Transaction T2 has record-granularity locks on File-2, and is waiting for T1 to release an XLOCK on one of these records.

• Transaction T3 wants to lock the entire database in shared mode. It is waiting for T1 and T2 to complete.

109

Granular Locking Example

• Transaction T2 has record-granularity locks on File-2, and is waiting for T1 to release an XLOCK on one of these records.

• Transaction T3 wants to lock the entire database in shared mode. It is waiting for T1 and T2 to complete.

110

Key-Range Locking• A key range is denoted by the first key in the

range and by the first key after the range.

– Example: [R, S) all k, such that R k < S.

• A fixed number of key ranges is predetermined

– Example: [A, N), [N, X), [X, )

• Locking protocol:

– A transaction acquires a lock on the key range before it accesses records in the key range.

– Since key ranges are granules within files, intent mode locks on the file (and on any coarser-granularity objects) must first be acquired in accordance with the granular lock protocol.

111

Why Key-Range Locking works ?

If the key ranges are thought of as predicates, they are simply predicate locks covering the records.

key-range locking also prevents phantoms.

Example: [R, S) all k, such that R k < S.

This is a predicate

112

Dynamic Key-Range Locks

• Standard key-range locking is not adaptive because there are a fixed number of key ranges.

• Dynamic key-range locking assigns a key range to every record in the file.

113

Dynamic Key-Range Locks(Example)

• Example: The file has three records: W, Y, Z.– Current key ranges:

[A, W), [W, Y), [Y, Z), [Z,) 1

– After the insertion of X, 1 becomes:[A, W), [W, X), [X, Y), [Y, Z), [Z, ) /* Split

– After the deletion of Y, 1 becomes:[A, W), [W, Z), [Z, ) /* Merge

• Dynamic key ranges appear and disappear. This makes the locking protocol more complex than static key-range locking.

1

1

1

114

Dynamic Key-Range Locking - Protocol

Given a sorted file of three records: W, Y, and Z. key ranges: [A, W), [W, Y), [Y, Z), [Z, )

• There are four operations of interest:

1. Read unique: read a unique record (say X), given its key.

The transaction T must SLOCK [W, Y) preventing anyone else from updating that key range.

Note: If the record is not found, the lock prevents a phantom insertion of X by another transaction

[A, W), [W, Y), [Y, Z), [Z, )

Read X

S

Insert X

115

Dynamic Key-Range Locking - Protocol (Cont’d)

Given a sorted file of three records: W, Y, and Z. key ranges: [A, W), [W, Y), [Y, Z), [Z, )


2. Read next: read the next record (i.e., Y ) after the record W.

The transaction T must• hold a lock on [W, Y) - to prevent any phantoms from

appearing in this key range, then • requests a SLOCK on key Y - this implicitly locks [Y, Z).

[A, W), [W, Y), [Y, Z), [Z, )

S

Insert X

S

Read next, i.e., read “Y”

116


(Cont’d) Given a sorted file of three records W, Y, Z.

key ranges: [A, W), [W, Y), [Y, Z), [Z, )


3. Insert: insert a record X between W and Y.

• The old key range [W, Y) (soon to be [W, X) ) must be locked in exclusive mode, then

• the new key range [X, Y) should be locked in exclusive mode.

[A, W), [W, Y), [X, Y), [Y, Z), [Z, )

Insert X

X X

New rangeBecome [W, X)

117


(Cont’d) Given a sorted file of three records W, Y, Z.

key ranges: [A, W), [W, Y), [Y, Z), [Z, )


4. Delete: delete record Y.

• First, lock [Y, Z) in exclusive mode, then

• Lock [W, Y) (soon to be [W, Z) ) in exclusive mode.

• When these two locks are granted, perform the delete.

[A, W), [W, Y), [Y, Z), [Z, )

Delete Y

X X

Become [W, Z)

118

Dynamic Key-Range Locks: Problem

• If a key-range lock has to wait to be granted; then when it is granted, the key range may have disappeared.

• Example: The file has three records W, Y, Z.current key ranges: [A, W), [W, Y), [Y, Z), [Z, )

T I

M E

T1 T2 Remark

locks [W, Y) in XLOCK

T1 wants to insert X

locks [X, Y) in XLOCK

Waits for [X, Y)T2 wants to read record previous to “Y”

T1 abortsthe key range returns to [W, Y)

lock on [X, Y) is granted

but [X, Y) disappears.

Solution: T2 should release the lock on [X,Y), and request [W,Y)

119

Lock Conversion• Question: Can a transaction

requests a look in shared mode, and later converts it to exclusive mode ?

– The transaction should not release the shared lock, and then request the exclusive lock.• Reason: 2P-locking is violated !

– If a lock is held in one mode and requested in a second mode, the request is converted to the max of the two modes

120

Lock Conversion Example

• If the lock is held in IX mode and requested in U made, then the request is converted to a request for a X mode lock.

conversion

Current mode

Requested mode

121

Lock EscalationIf the system makes a mistake and uses fine granularity when coarse granularity is appropriate, the lock system may run out of storage.

– Typical solution: If the number of locks held by a transaction reaches an escalation threshold, the lock manager converts fine-granularity locks to coarse locks.

– Example: • looks for an IS lock with many children set in S mode, • converts the parent IS mode lock to an S mode, and • releases all the S mode locks on the children.

Page 101

Record112

Record113

Record…

IS

S S

Page 101

Record112

Record113

Record…

SLock escalation Records are

implicitly lockedin shared mode

122

Lock Escalation – Rdb’s Approach

• It defaults to file-granularity locks.

• If there is any contention on the file-granularity lock, each holder of the lock de-escalates to finer granularity on demand.

/rdb is a high-performance relational database management and application development system designed for Unix and implemented as a suite of shell-level commands.

123

Hotspots• The virtue of page-granularity locking is that:

– It is very easy to implement,

– It works well in almost all cases, and

– It can be used to give phantom protection (by locking the page on which the phantom would have to appear).

• However, page-granularity locking can create hotspots.Examples:

– Directories are typically small, high-traffic read-write databases. They can become hotspots.

– The debit/credit transaction demonstrates main-memory hotspot problems. All the branch records (usually less than 100) typically fit in a couple of pages.

– Inserting in a sequential file can give page locking systems heartburn, since locking the page containing the end of the file prevents any other transaction from inserting at the end of the file.

124

Sequential Nested Transaction Locking

• The effects of a nested transaction are made durable and public only when the top-level transaction invokes COMMIT work.

• Implementation:

– All subtransactions run under the same TRID.

– Locks are maintained as a stack. When the transaction does a nested BEGIN work, that establishes a savepoint in the stack.

– If the transaction does a ROLLBACK to one of these savepoints, all locks subsequent to the lock in the savepoint are released (i.e., popped from the stack).

125

Parallel Nested Transaction Locking

• The parallel subtransactions are each viewed as atomic units (they have A, C, and I, but not D of ACID)– Each subtransaction gets a unique TRID.– The nested transactions are viewed as

nodes of the transaction family tree.

• At commit, both inherited and acquired locks are given back to the parent; but at ROLLBACK only inherited locks are returned.

126

Parallel Nested Transaction Locking(cont’d)

When a transaction requests a lock that is already held by another transaction, the following test is run:

Is the other transaction in the same family?– If yes, is it an ancestor ?

• If yes, inherit 1• If no, wait, then inherit. 2

– If no, wait. 31

2

1

Family F1 Family F2

3

acquired

32

127

Deadlocks• A situation in which each transaction of the

deadlock set is waiting for another member of the set.

• These transactions will not advance unless one transaction stops waiting.

A solution: one of the transactions must rollback.

Slock1(x)

Slock2(x) Xlock1(x)

Xlock2(x)

Read-Write dependency

Read-Write dependency

time

T1T2

The Wait-for graph

128

Deadlock Avoidance Techniques

1. Linearly ordering resources and requesting them only in that order (avoiding wait-for cycles).

2. Asking job to predeclare their maximum needs.

T1

T2 (WAIT)

Only Waiting for a transaction further to the right

T2 waits for T1 T1 cannot wait for T2

129

Deadlock Detection

1. Whenever a transaction waits more than a certain time,

declare that something is wrong, and

rollback that transaction.

2. After a transaction times out, the system runs a deadlock detector that looks for cycles in the wait-for graph.

130

Lock Data Structure• Each lock has two lists: granted list & waiting list• It is also convenient to have a transaction wait list

to know where a transaction is waiting

l2grantedlist

waitinglist

l1

• The edge T T should be added to the wait-for graph if T is in the waiting list and:– T is in the granted list or is ahead of T in the

waiting list, and– the lock modes m and m are incompatible.

t2 is ahead of t3 in

waiting list

131

Wait-for Graph and Deadlock Detection

The wait-for graph can be examined for cycles by doing a depth-first search that runs in time proportional to the number of edges.

Visiting a node (i.e., transaction) that has been visited before

A loop is detected A deadlock

132

Distributed Deadlock

• The transaction wait list is distributed.

• Typically, each site maintains a local fragment of the transaction wait list containing all transaction waiting at that node.

How to do global deadlock detection ?

133

Centralized Deadlock Detection

• Every site sends its lock request/release requests to a central control site which perform deadlock detection and resolution

• Advantage: Simple

• Disadvantages– Inefficient– Single point of failure– Phantom deadlock (a cycle caused by a

transient arc)

134

Phantom Deadlocks

• Since the wait-for graph is constantly changing, it is not possible to get a consistent picture of the graph.

• Phantom deadlocks are due to cycles in the graph caused by transient arcs.

135

Phantom Deadlocks– At time t1

T T T T Site 1 Site 2 Site3

(T is finishing (collecting subgraphs) (serving T) writing the log)

– At time t2

Good news: the deadlock detector will not miss any real deadlocks.

Collecting subgraphs

log lock

Site 1(completed the log operation for T, currently serving T)

Site 2(a phantom deadlock

is detected)

Site 3(serving T)

T T

T requests a service at site 3

T T

Transienttarc

Collecting subgraphs

136

Sharing Local Information• Special node “External” (EX) abstracts non-local

portion of the global wait-for graph

• For each cycles (e.g., EXT1T2T3 T4 EX), sends this path to all sites where a subtransaction of T1, T2, T3, T4 may reside

T2

T3

T1

T4

EX

Some transaction outside is waiting for

T1

T4 is waiting for some outside transaction

137

Path Pushing• Share wait-for information on potential global

cycles

• Each site– waits for wait-for information from other nodes– combines with local wait-for information– breaks cycles if detected

EX

Potential global cycle

EXEX

A loop Deadlock !

138

Challenge

• There is no standard representation of the wait-for graph.

• Not all RMs provide their part of the wait-for graph.

139

Deadlock Resolution

• Once a deadlock is found, it must be broken.

The standard resolution technique is to roll back the least expensive

transactions, e.g., the one with the shortest logs.

140

Deadlock: Summary• Wait-for graphs have the following

characteristics:

– sparse (waits are very rare)

– Most cycles are very short (two)

– Cycles are very rare

• Most systems use the following approach:

– The system falls back on timeout, plus

– a simple local deadlock detector that detects local deadlocks.

Address global cycle

141

A Simple Model for Deadlock Analysis

• The system consists of R records.

• There are n + 1 concurrent transactions.

• Each transaction performs r + 1 actions. Each action access a random record from the set of R records.

• n·r << R : that is, most of the database is unlocked most of the time.

. . .

T T T T T. . .

Database size:R records

r + 1 actions

n + 1 concurrenttransactions

142

Probability of Deadlock (1)The probability that a single request waits is PW = ( n · r/2 ) / R = n · r / 2·R

Avg. num of locks held by each transaction (assumption)

The n other transactions

. . .

T T T T T. . .

Database size:R records

r + 1 actions

n + 1 concurrenttransactions

143

Probability of Deadlock (1)The probability that a single request waits is PW = ( n · r/2 ) / R = n · r / 2·R

The probability that a particular transaction T, waits in its life time is PW(T) = 1 – (1 – PW)r

= 1 – [ 1 – ]

Avg. num of locks held by each transaction (assumption)

The probability that a single request does not have to wait.

r

PWr

rPW

rPW

r

...

212

nr<<R PW<<1 these high-order terms can be dropped

PW(T) = n PW(T) = n · rr2 2 / 2·R/ 2·R

The n other transactions

None of r requests has to wait

144

Probability of Deadlock (2)

The probability that some transaction T is deadlock:

PD(T) = PW(T)2 / n + 1 · PW(T)3 + 2 · PW(T)4 + ...

...

3length of cycle

a sexperience

Ty Probabilit

2length of cycle

a sexperience

Ty Probabilit

)(

TPD

1/n · PW(T) Prob. for waiting for a specific

transaction (out of n transactions)

In general, the probability of a cycle of length i is proportional to PW(T)i

Since we typically have PW(T)<0.1 These terms can be dropped.

Prob. for waiting for some transaction –

PW(T)

T1

T2

145

Probability of Deadlock (3)The probability that any transaction deadlocks:

PD = PD(T1) + PD(T2) + … + PD(Tn+1)

PD n · PD(T) = n2 · r4 / 4·R2

Multiprogramming level must be kept low

Fine-granularity locking, browse mode locking and shared locks are important. They all tend to reduce the transaction collision cross sections.

deadlocks are very rare

PD(T) = PW(T)2 / nPW(T) = n r2 /

2R

146

Transaction’s Cross Section

Transaction’s cross section is the time-space product of the amount of data the transaction locks and the lock duration.

Tim

e

Locks

T1

T2T3

T4

Transaction’s cross

section of T4

147

Reducing transaction’s collision cross section

• T2 and T3 occur concurrently. However, they are isolated because they access different data sets.

• T3 and T4 access the same data. However, they are isolated because they occur during different time spans.

• Since T2 collides with T1, isolation problems can occur.

Tim

e

Locks

T1

T2 T3

T4

Collision Cross Section

148

Reducing collisionReducing the transaction’s collision cross section minimizes lock wait increases concurrency &

reduces deadlocks

Tim

e

Locks

T1

T2 T3

T4

Potential problem

Critical for hot spots

Need milk

149

Field Calls

• Field calls help to reduce the collision cross section.

• Field call is an action on a specific hotspot record (e.g., milk inventory in a supermarket).

• The action consists of two parts:

a predicate, e.g., having milk in the inventory ?

a transform, e.g., sell some of the milk cartons

150

A Field Call Example

Update inventorySet quantity_on_hand = quantity_on_hand - :deltaWhere item = “milk” and quantity_on_hand :delta;

Predicatequantity_on-hand > “delta

Transformquantity_on-hand = quantity_on_hand

- :delta

151

Idea

• After checking the inventory, immediately release the share lock

– To increase concurrency

• At commit time, check the inventory again before the sale

– To be sure there are still enough items in the inventory at this time

152

Field Calls - Details1. Lock the record corresponding to “Milk

Inventory” in short duration shared mode.2. Test the predicate against the “Milk Inventory”

record, and release the shared lock afterward. 3. If the predicate is true, the system generates a

REDO log record containing the predicate and the transform.

4. At commit phase 1, 1. All deferred REDO log records are examined.2. Shared locks are acquired on predicate-only records,3. Exclusive locks are acquired on records mentioned in

transforms.

5. At commit phase 2. 1. If all predicates remain true, apply each transform

and free the locks 2. Otherwise, rollback the transaction

Field Calls - Illustration

153

timeT1 begins predicate

test

Field call

Re-evaluate predicate

Phase1commit

T1 ends

Phase 2 commit

Locks are available during this time

154

Field calls: Exampleupdate inventory Set qoh = qoh + :delta where item = “milk” AND

qoh delta;

Milk100

0Original

qoh

155

Field calls: Example

Milk100

0

-5

+300

-10

Milk

990

Milk129

0

Milk128

5

CheckoutClerk C1

StockingClerk S

CheckoutClerk C2

C2updates

Supdates

C1updates

Original qoh

C1 S C2 C2 S C1

C1 S C2

C2 S C1

update inventory Set qoh = qoh + :delta where item = “milk” AND

qoh delta;

time

156

Field calls: Recovery•Field calls never have any transaction undo

work.

If the transaction aborts, the field calls have not made any changes to the database; thus, they are already “undone”.

•Redo of field calls is a little more subtle.

Since transformations are deferred to phase 2 of commit, it is safest to delay inserting field call transforms into the REDO log until the end of phase 1 of commit.Reason: The field call transforms will appear in the order that they were applied (rather than the order in which the field calls themselves were issued).

157

time transaction T transaction T log 1. t(h) …, t(h) 2. t(h) …, t(h), t(h) 3. commit 4. commit redo order

• Effect (commit order): t(t(h))

• System crashed, the redo logic reconstructed the value of h: t(t(h)).

Note: commit order redo order If t(t(h)) t(t(h)) the wrong value is reconstructed.

Field calls: Recovery Example

transactionT

hotspot record

h

transactionT’

t t

Example:

158

Field Calls – Defer REDO log

1. Lock the record corresponding to “Milk Inventory” in short duration shared mode.

2. Test the predicate against the “Milk Inventory” record, and release the shared lock afterward.

3. If the predicate is true, the system generates a REDO log record containing the predicate and the transform.

4. At commit phase 1, 1. All deferred REDO log records are examined.2. Shared locks are acquired on predicate-only records,3. Exclusive locks are acquired on records mentioned in

transforms.

5. At commit phase 2. 1. If all predicates remain true, apply each transform

and free the locks 2. Otherwise, rollback the transaction

Defer until end of Phase

1

159

Refinement of Field CallIf we can preserve the truth of the predicate between the time the transaction first makes the field call and the time the predicate is revaluated at phase 1 of commit, then we can prevents transaction predicate failure at commit, and the consequent transaction aborts.

timeT1 begins predicate

test

Field call

Re-evaluate predicate

Phase1commit

Try to preserve the

predicate

T1 ends

Phase 2 commit

QoH > 7QoH > 7 QoH > 7QoH > 7

160

Escrow Locking

• Associated with each hotspot field is a range of values.

[m, n]

• For each new field call, the predicate is tested against both m and n.

The current value (in the database)

The new value if all the pending field call transforms are applied.

Note: m = n if there is no pending field call.

161

Escrow Locking ExampleStandard Field Call

162

Escrow Locking ExampleStandard Field Call

Rollback a younger

transaction

Rollback an older

transaction Note: We need to test the predicates

against both end values because the operator could be a “ + ” (instead of “ - ”), i.e., do not want to overstock.

”50” is not

enough for T3

”50” is not

enough for T3

Note: m = n if there is no pending field call

163

Conventional Locking

Conventional locking techniques are pessimistic:

– They assume a high degree of contention among concurrent transactions.

– A certain degree of checking is done before a database operation can be executed.

164

Optimistic Concurrency Control

Do not perform any locking at all. A transaction is composed of three phases:

Read Phase Validation Phase

Write Phase time

Updates are applied only to local copies of the data items kept in the transaction workspace.

Checking to ensure the serializability will not be violated if the updates are applied to the database.

If validation is successful then updates are applied to the database else the updates are discarded and the transaction is restarted

Optimistic Concurrency Control - Validation Phase

• Each transaction Ti is assigned a timestamp TS(Ti) at the beginning of its validation phase

• To validate Tj, one of the following conditions must hold for every Ti such that TS(Ti) < TS(Tj):

1. Ti completes before Tj begins (They are isolated)

2. Ti completes before Tj starts its Write phase, and Ti does not writewrite any database object read by Tj

Tj may read objects while Ti is still modifying objects. However, there is no conflict

3. Ti completes its Read phase before Tj completes its Read phase, and Ti does not write any database object that is either read or written by Tj

Ti and Tj may write objects at the same time. However, their write sets do not overlap

165

Test against all older

transactions

166

Optimistic Concurrency Control: Problem

• Advantage: No checks are made while the transaction is running locking is not required.

• Disadvantage:

– When interference is significant, this approach is worse than conventional locking

• Conventional locking would serialize the transactions, causing them to wait for one another.

• Optimistic techniques would let all the concurrent transactions run and then abort all but one of them.

– Field calls plus escrow reads is better

Better !

Better !

167

Timestamp Ordering• A timestamp is a unique identifier created

by the DBMS to identify a transaction.

– Typically, timestamps are assigned in the order in which the transactions are submitted to the system.

• Each database item X has two timestamp values:

– read_TS(X): The largest of all the timestamps of transactions that have successfully read item X

– write_TS(X): The largest of all the timestamps of transactions that have successfully written item X

Idea: Using the database according to the order of arrival

168

Timestamp Ordering - Protocol

•Transaction T issues a write_item(X):a) If read_TS(X) > TS(T) or write_TS(X) > TS(T),

then abort and roll back T.

b) If (a) does not occur, then execute the write_item(X) and set “write_TS(X) = TS(T).”

•Transaction T issues a read_item(X):a) If write_TS(X) > TS(T),

then abort and rollback T.

b) If write_TS(X) TS(T): execute the read_item(X) and set “read_TS(X) = max (TS(T), read_TS(X))”

Some younger transaction has done the write

Transactions can share share

locks

Too late to read X

169

Timestamp ordering: Example

Concurrent transactions

T1 T2 T3

TS(T1)=200 TS(T2)=150TS(T3)=17

5

READ B

READ A

READ C

WRITE B

WRITE A

WRITE C

ABORT

WRITE A

ABORT

170

Timestamp ordering: Example

Concurrent transactions Database objects

T1 T2 T3 A B CTS(T1)=200 TS(T2)=150

TS(T3)=175 RT=0, WT=0 RT=0, WT=0 RT=0, WT=0

READ B RT=200, WT=0

READ A RT=150, WT=0

READ C RT=175, WT=0

WRITE B WT=200, RT=200

WRITE A RT=150, WT=200

WRITE C

ABORT

WRITE A

ABORT

TS(T2)<RT T2 is too late

!

TS(T3)<WT(A) T3 is too late !

171

Timestamp ordering

• Deadlock does not occur.

• However, cyclic restart may occur if a transaction is continually aborted and restarted (starvation).

172

Multiversion Concurrency Control (1)

Each time an item is written, we create a new version of the item and give it a write-time equal to the timestamp of the transaction doing the writing.

Xi (WT = 10)

Xj (WT = 20) T

TS(T) = 20

WRITE

Older versio

n

Latest versio

n

173


When a transaction with timestamp t wishes to read an item X, it finds the version of X with the highest write-time not exceeding t and reads that version.

Xi (WT = 10)

Xj (WT = 20)

Xk (WT = 30)

T

TS(T) = 25

READ

Threeversions of X

Better than Timestamp Ordering

Too late !

174


When a transaction T with timestamp t wishes to write X, and we find that there is a version Xi of X with a write-time less than t and a read-time greater than t : ABORT T.

Xi (WT = 10)

Xj (WT = 20)Threeversions of X T3

TS(T3) = 50

WRITE

T2TS(T2) =

60

READ

No

Xk (WT = 30 RT = 60)

175

Multiversion Concurrency Control: Example

At step (4), B0 is still available to T1. We do not have to abort T1. Note: WT(B1) > TS(T1)

T1 T2 A0 A1 B0 B1

TS(T1) = 100

TS(T2) = 200

RT = 0, WT = 0

RT = 0, WT = 0

READ ART = 100,

WT = 0

READ ART = 200,

WT = 0

WRITE BWT = 200,

RT = 0

READ BRT = 100, WT = 0.

1

2

3

4

5

176

Multiversion Concurrency Control: Problems

• Advantage: Update-in-place makes it easy to find out the current value, but one must hunt through the log to reconstruct the history of data items. Multiversion concurrency control does not have this problem.

• Disadvantages:– Read-only transactions can actually be update

intensive (updating the timestamp)– Long transactions may get aborted continually.– There is nothing resembling a lock granularity

scheme.– Frequently updated records (hotspots) are not

helped by version-oriented database.

Documents

1 Module 4 Isolation Concepts COP 6730. 2 System State The system state consists of objects related in certain ways. These relationships are best thought