UCDavis, ecs251 Spring 2007 04/17/2007Transactions1 Operating System Models ecs251 Spring 2007: Operating System Models #2: Transactions Dr. S. Felix

04/17/2007 Transactions 1

UCDavis, ecs251Spring 2007

ecs251 Spring 2007:

Operating System ModelsOperating System Models#2: Transactions

Dr. S. Felix Wu

Computer Science Department

University of California, Davishttp://www.cs.ucdavis.edu/~wu/

[email protected]



TransactionTransaction

A sequence/program of operations {read, write} on a set of “shared” variables



A Transaction SystemA Transaction System

A set of transactions being executed and sharing a set variables.

A lot of uncontrollability:– Failures of everything and any time– Distributed nature– Unpredictable scheduling– Dynamics about transactions themselves

Program changes, Self aborting, Birth,…



Applications of TransactionsApplications of Transactions

Database/Information System Distributed Mobile computing Distributed File System Fault Tolerant computing



Transaction Properties: ACIDTransaction Properties: ACID

Atomicity (all or nothing) Consistency (consistent state transition) Isolation (intermediate results) Durability (persistent)



Transaction Properties: ACIDTransaction Properties: ACID

Atomicity (all or nothing) Consistency (consistent state transition) Isolation (intermediate results) Durability (persistent)

Let’s not worry about the details for now…



(a)R(X)W(X)R(Y)W(Y)

(b)R(Z)R(Y)W(Y)R(X)W(X)

(c)R(Y)R(Z)W(Y)W(Z)

Three Transactions: a,b, and cAssuming we have only one copy of X, Y, & ZRt(O): Transaction t READ object OWt(O): Transaction t WRITE object O



R(X)W(X)R(Y)W(Y)

R(Z)R(Y)W(Y)R(X)W(X)

R(Y)R(Z)W(Y)W(Z)

Transaction Execution Historytime



R(X)W(X)R(Y)W(Y)

R(Z)R(Y)W(Y)R(X)W(X)

R(Y)R(Z)W(Y)W(Z)


Tb >> Tc >> Ta or “bca”



R(X)W(X)

R(Y)W(Y)

R(Z)R(Y)W(Y)

R(X)

W(X)

R(Y)R(Z)

W(Y)W(Z)




R(X)W(X)

R(Y)W(Y)

R(Z)R(Y)W(Y)

R(X)

W(X)

R(Y)R(Z)

W(Y)W(Z)

Does this schedule look OK? time



R(X)W(X)

R(Y)W(Y)

R(Z)R(Y)W(Y)

R(X)

W(X)

R(Y)R(Z)

W(Y)W(Z)

Y only: abc, acb, bac, bca, cab, cba ??timea b c

Y Y

Y



R(X)W(X)

R(Y)W(Y)

R(Z)R(Y)W(Y)

R(X)

W(X)

R(Y)R(Z)

W(Y)W(Z)

X only: abc, acb, bac, bca, cab, cba ??timea b c



R(X)W(X)

R(Y)W(Y)

R(Z)R(Y)W(Y)

R(X)

W(X)

R(Y)R(Z)

W(Y)W(Z)

Z only: abc, acb, bac, bca, cab, cba ??timea b c



R(X)W(X)

R(Y)W(Y)

R(Z)R(Y)W(Y)

R(X)

W(X)

R(Y)R(Z)

W(Y)W(Z)


a b cY

YY,Z

X


UCDavis, ecs251Spring 2007 Operations in Operations in CoordinatorCoordinator

interfaceinterfaceBeginTransaction() -> trans;

starts a new transaction and delivers a unique TID trans. This identifier will be used in the other operations in the transaction.

EndTransaction(trans) -> (commit, abort);ends a transaction: a commit return value indicates that the transaction has committed; an abort return value indicates that it has aborted.

AbortTransaction(trans);aborts the transaction.



The Transaction ModelThe Transaction ModelPrimitive Description

BEGIN_TRANSACTION Make the start of a transaction

END_TRANSACTION Terminate the transaction and try to commit

ABORT_TRANSACTION Kill the transaction and restore the old values

READ Read data from a file, a table, or otherwise

WRITE Write data to a file, a table, or otherwise



Transaction Execution HistoriesTransaction Execution Histories

Successful Aborted by client Aborted by server BeginTransactionBeginTransaction BeginTransactionoperation operation operation operation operation operation

server abortstransaction

operation operation operation ERRORreported to client

EndTransaction AbortTransaction


UCDavis, ecs251Spring 2007 Serial equivalenceSerial equivalence

if each one of a set of transactions has the correct effect when done on its own alone, then if they are done one at a time in some order the effect will be correct

a serially equivalent interleaving is one in which the combined effect is the same as if the transactions had been done one at a time in some order– abc, acb, bac, bca, cab, or cba

the same effect means– the read operations return the same values (to one order)– the instance variables of the objects have the same values

at the end (of each transaction).

•


UCDavis, ecs251Spring 2007 SerializabilitySerializability

BEGIN_TRANSACTION read X; read Y; write YEND_TRANSACTION

(a)

BEGIN_TRANSACTION read X; read Z; write Z;END_TRANSACTION

(b)

BEGIN_TRANSACTION read Y; read Z; read X;END_TRANSACTION

(c)

Illegalr[X]a, r[X]b, r[Z]b, r[Y]a, r[Y]c, w[Z]b, w[Y]a, r[Z]c, r[X]cSchedule 3

Legalr[X]a, r[X]b, r[Z]b, r[Y]a, w[Z]b, w[Y]a, r[Y]c, r[Z]c, r[X]cSchedule 2

Legalr[X]a, r[Y]a, w[Y]a, r[X]b, r[Z]b, w[Z]b, r[Y]c, r[Z]c, r[X]cSchedule 1

r[X]a, r[X]b, r[Z]b, r[Y]a, r[Y]c, r[Z]c, w[Z]b, r[X]c, w[Y]a

r[X]a, r[X]b, r[Z]b, r[Y]c, r[Y]a, w[Z]b, r[Z]c, r[X]c, w[Y]a


UCDavis, ecs251Spring 2007 operation conflict rulesoperation conflict rules

Conflicting operations a pair of operations conflicts if their combined effect depends on the order in

which they were performed– e.g. read and write (whose effects are the result returned by read and the value

set by write)

Operations of differenttransactions

Conflict Reason

read read No Because the effect of a pair of read operations

does not depend on the order in which they are

executed

read write Yes Because the effect of a read and a write operation

depends on the order of their execution

write write Yes Because the effect of a pair of write operations

depends on the order of their execution


UCDavis, ecs251Spring 2007 SerializabilitySerializability

Given a transaction execution history, check all the operation conflicts.– Check whether you can find a serializable

schedule to satisfy all the conflicts, or– Check if the conflict dependency graph is

acyclic or not.


UCDavis, ecs251Spring 2007 Concurrency ControlConcurrency Control

We might not be able to control the scheduler.

Let’s use some mechanisms (such as mutex, cond, or other) to stop certain threads to avoid “non-serializable” execution history.– locking– time-stamping– optimistic approach


UCDavis, ecs251Spring 2007 Lock-based CCLock-based CC

Two extra operations:– lock and unlock

The problem is where and when to put these new operations??



(a)lock(X)R(X)W(X)unlock(X)lock(Y)R(Y)W(Y)unlock(Y)

(b)lock(Z)R(Z)unlock(Z)lock(Y)R(Y)W(Y)unlock(Y)lock(X)R(X)W(X)unlock(X)

(c)lock(Y)R(Y)lock(Z)R(Z)W(Y)unlock(Y)W(Z)unlock(Z)



lock(X)R(X)W(X)unlock(X)

lock(Y)R(Y)W(Y)unlock(Y)

lock(Z)R(Z)unlock(Z)lock(Y)R(Y)W(Y)unlock(Y)

lock(X)R(X)

W(X)unlock(X)

lock(Y)R(Y)lock(Z)R(Z)

W(Y)unlock(Y)W(Z)unlock(Z)



(a)lock(X)lock(Y)lock(Z)R(X)W(X)R(Y)W(Y)unlock(Z)unlock(Y)unlock(X)

(b)lock(X)lock(Y)lock(Z)R(Z)R(Y)W(Y)R(X)W(X)unlock(Z)unlock(Y)unlock(X)

(c)lock(X)lock(Y)lock(Z) R(Y)R(Z)W(Y)W(Z)unlock(Z)unlock(Y)unlock(X)



(a)lock(Y)lock(X)R(X)W(X)R(Y)W(Y)unlock(X)unlock(Y)


(c)lock(Y)lock(Z) R(Y)R(Z)W(Y)W(Z)unlock(Z)unlock(Y)



(a)lock(X)R(X)W(X)Lock(Y)Unlock(x)R(Y)W(Y)unlock(Y)


(c)lock(Y) R(Y)Lock(z)R(Z)W(Y)Unlock(Y)W(Z)unlock(Z)



lock(X)

lock(Y)R(X)W(X)R(Y)W(Y)unlock(Y)unlock(X)

lock(X)lock(Y)lock(Z)R(Z)R(Y)W(Y)R(X)W(X)unlock(Z)unlock(Y)

unlock(X)

lock(Y)lock(Z) R(Y)R(Z)

W(Y)W(Z)unlock(Z)unlock(Y)

a b c


UCDavis, ecs251Spring 2007 Two-Phase LockingTwo-Phase Locking

Two-phase locking.


UCDavis, ecs251Spring 2007 Strict Two-Phase LockingStrict Two-Phase Locking

Strict two-phase locking.

Commitor Abort

1. prevent dirty read and immature write2. we don’t really know where the lock point is!!


UCDavis, ecs251Spring 2007Lock compatibility (Lock compatibility (readread, , writewrite

and and commitcommit locks) locks)

For one object Lock to be set

read write commit Lock already set none OK OK OK

read OK OK wait

write OK wait

commit wait wait


UCDavis, ecs251Spring 2007 Time-Stamp OrderingTime-Stamp Ordering

“Serial Equivalence” One particular order, e.g., “abc”. TSO sets the “order” from the beginning and enforce that

the “execution history” must strictly follow that order.– If we decide “abc”, then we will not allow “bac”.

Problem: how to assign the order among transactions?



Time Stamp OrderingTime Stamp Ordering TS_start (T): each T will get a unique TS.

– It should remain the same until abort/commit.– First Come First Serve.

For each object X:– TS_read (X):

The largest TS_start among T’s who had read X

– TS_write(X): The largest TS_start among T’s who had written X

– The values only monotonically increase. Write: TS_start(T) >= TS_read(X)

– T’s future has not been read.– TS_start(T) < TS_write(X) skip the write but continue.

Read: TS_start(T) >= TS_write(X)– T’s future has not been written.


UCDavis, ecs251Spring 2007 Operation conflicts for Operation conflicts for

timestamp orderingtimestamp ordering

Rule Tc Ti

1. write read Tc must not write an object that has been read by any Ti where this requires that Tc ≥ the maximum read timestamp of the object.

2. write write Tc must not write an object that has been written by any Ti where

Ti >Tc

this requires that Tc > write timestamp of the committed object.

3. read write Tc must not read an object that has been written by any Ti where this requires that Tc > write timestamp of the committed object.

Ti >Tc

Ti >Tc


UCDavis, ecs251Spring 2007 (a)

R(X)W(X)R(Y)W(Y)

(b)R(Z)R(Y)W(Y)R(X)W(X)

(c)R(Y)R(Z)W(Y)W(Z)


UCDavis, ecs251Spring 2007TSstart

a = 1R(X) = 1W(X) = 1

TSstartb = 2

R(Z) = 2

TSstartc = 3

R W

X

Y

Z

1 1

2

0 0

0

R W

X

Y

Z

0 0

0

0 0

0



a = 1R(X) = 1W(X) = 1

R(Y) = 3(v1<3 == R(Y))

TSstartb = 2

R(Z) = 2

R(Y) = 3 (v2<3)

TSstartc = 3

R(Y)= 3R(Z)= 3

R W

X

Y

Z

1 1

3

3 0

0

(1 > 0 == W(Y))

R W

X

Y

Z

1 1

2

0 0

0

(2 > 0 == W(Y))



a = 1R(X) = 1W(X) = 1

R(Y) = 3 (1<3)

W(Y) abort(1 < (R(Y) == 3))

TSstartb = 2

R(Z) = 2

R(Y) = 3 (2<3)

W(Y) abort(2 < (R(Y) == 3))

R(X)W(X)

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3

R W

X

Y

Z

1 1

3

3 3

3



a = 1R(X) = 1W(X) = 1

R(Y) = 2

W(Y) = 3

TSstartb = 2

R(Z) = 2R(Y) = 2

W(Y) = 2

R(X) = 2W(X) = 2

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3

Which one(s) will commit?



a = 1R(X) = 1W(X) = 1

R(Y) = 2

W(Y) = 3

TSstartb = 2

R(Z) = 2R(Y) = 2

W(Y) = 2

R(X) = 2W(X) = 2

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3



a = 1R(X) = 1W(X) = 1

R(Y) = 2

W(Y) = 3

TSstartb = 2

R(Z) = 2R(Y) = 2

W(Y) = 2

R(X) = 2W(X) = 2

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3



a = 1R(X) = 1W(X) = 1

R(Y) = 2

W(Y) = 3

TSstartb = 2

R(Z) = 2R(Y) = 2

W(Y) = 2

R(X) = 2W(X) = 2

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3



a = 1R(X) = 1W(X) = 1

R(Y) = 2

W(Y) = 3

TSstartb = 2

R(Z) = 2R(Y) = 2

W(Y) = 2

R(X) = 2W(X) = 2

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3



a = 1R(X) = 1W(X) = 1

R(Y) = 2

W(Y) = 3

TSstartb = 2

R(Z) = 2R(Y) = 2

W(Y) = 2

R(X) = 2W(X) = 2

TSstartc = 3

R(Y)= 3R(Z)= 3

W(Y)= 3W(Z)= 3



T1:begin transactionquery cs.ucdavis.eduquery x123.google.comquery mail.yahoo.comend transaction

T2:begin transactionquery cs.ucdavis.eduupdate cs.ucdavis.eduquery x123.google.comupdate x123.google.comend transaction

T3:begin transactionquery mail.yahoo.comupdate mail.yahoo.comquery x123.google.comupdate x123.google.comend transaction

DNS Transactions

Consistent Name-IPAddr Mappingse.g., web site upgrading



HW#2 Programming PartHW#2 Programming Part Transaction Execution History

– Operation {R, W}– Object Identifier (an integer)– Transaction Identifier (an integer)

Answer:– Serializable or not– Can this input execution history be produced by 2PL, TSO, or

OCC? Due Date: May 31, 2007 (1~2 students per team) I will provide the test cases. We will do “interactive grading”!



HW#2 Writing PartHW#2 Writing Part I will post a few questions (like HW#1)

regarding distributed file systems (NFS, AFS, GFS, and Coda).

During the interactive grading session, I will ask questions as well.


UCDavis, ecs251Spring 2007 OCC: OCC:

Optimistic Concurrency ControlOptimistic Concurrency Control

Execute theTransaction

Validation

logging

Commit or abort??


UCDavis, ecs251Spring 2007 Three Phases in OCCThree Phases in OCC

Working phase–the transaction uses a tentative version of the objects it accesses (dirty reads can’t occur as we read from a committed version or a copy of it)–the coordinator records the readset and writeset of each transaction

Validation phase–at closeTransaction the coordinator validates the transaction (looks for conflicts)–if the validation is successful the transaction can commit.–if it fails, either the current transaction, or one it conflicts with is aborted

Update phase–If validated, the changes in its tentative versions are made permanent.

–read-only transactions can commit immediately after passing validation.


UCDavis, ecs251Spring 2007 OCC Data StructureOCC Data Structure

Object Transaction

– ReadSet: objects read by T– WriteSet: objects written by T– Shadow Copies: copies of objects written by T

but not yet committed (temporary copies)

RealR

W

R

W


UCDavis, ecs251Spring 2007 OCC OperationsOCC Operations

T.read (Object Obj)– add Obj to T.ReadSet– if Obj in T.WriteSet, return T.Copies(Obj)– otherwise return Real(Obj);

T.write (Object Obj, Value V)– add Obj to T.WriteSet– if Obj in T.WriteSet, update T.Copies(Obj)– otherwise, create T.Copies(Obj), and update it.


UCDavis, ecs251Spring 2007 How to Validate??How to Validate??


Validation

logging



Assign the Transaction number– similar to the TSO, but until the beginning of the

validation phase.



Assign the Transaction number– similar to the TSO, but until the beginning of the

validation phase. According to the “Order”, try to detect conflicts

for a particular transaction, Tcurrent

– Have Tcurrent read anything that have been updated since then?

– Validate against all the transactions committed earlier, but finished their update phase after the starting time of the transaction.

“Backward Validation” “Forward” “Serial Validation” “Parallel”



Three Phases in OCCThree Phases in OCC

Working Validation Update

Starting Time of the Transaction Commit


UCDavis, ecs251Spring 2007 OCC transactionsOCC transactions

Earlier committedtransactions


T1

Tcurrent

Transactionbeing validated

T2

T3

Later activetransactions

active1

active2


UCDavis, ecs251Spring 2007 Which ones should we Which ones should we

consider?consider?

Earlier committedtransactions


T1

Tcurrent

Transactionbeing validated

T2

T3

Later activetransactions

active1

active2



OCC Conflict DetectionOCC Conflict Detection Transactions entering the commit queue. Conflicts:

– if T reads something that has been updated by “earlier” committed transactions.

TR-setW-set

TR-setW-set

TR-setW-set

TR-setW-set

TR-setW-set

committed currentcommitted



Why not Write-Write conflicts?Why not Write-Write conflicts? WW conflicts:

– In OCC, all the writes are performed in one shot (atomically)!!



W(X)W(Z)

(b)W(Y)W(X)

(c)W(Y)W(Z)



W(X)

W(Z)

(b)

W(Y)W(X)

(c)

W(Y)W(Z)



validation

W(X)W(Z)

(b)validation

W(Y)W(X)

(c)

validation

W(Y)W(Z)


UCDavis, ecs251Spring 2007 Validation of TransactionsValidation of Transactions

Backward validation of transaction Tv

boolean valid = true;for (int Ti = startTn+1; Ti <= finishTn; Ti++){

if (read set of Tv intersects write set of Ti) valid = false;}

Forward validation of transaction Tv

boolean valid = true;for (int Tid = active1; Tid <= activeN; Tid++){

if (write set of Tv intersects read set of Tid) valid = false;}


UCDavis, ecs251Spring 2007 An OptimizationAn Optimization

T102

R-setW-set

T101

R-setW-set

T97

R-setW-set

T92

R-setW-set

T103

R-setW-set


conflict

Problem: ReadSet (T103) intersects with WriteSet (T101)

Assume thatWriteSet (T103) does NOT intersect with ReadSet (T101)Do we have any hope NOT to abort T103?


UCDavis, ecs251Spring 2007 Forward ValidationForward Validation

Try to detect conflicts for other transactions against Tcurrent

– Have Tcurrent updated anything that have been read EVER?

– Validate against all the transactions not yet committed.

Every Object should have a “ReadSet” (which transactions have read this object).


UCDavis, ecs251Spring 2007 OCC - Serial ValidationOCC - Serial Validation

committed committing working/in progress

transaction numberbeing assigned

LatestCommittedtransaction


UCDavis, ecs251Spring 2007 Parallel ValidationParallel Validation

Can I validate multiple transactions at the same time?



How to Validate in Parallel??How to Validate in Parallel??

Assign the Transaction number– similar to the TSO, but when??

According to the “Order”, try to detect conflicts for a particular transaction, Tcurrent

– Have Tcurrent read anything that have been updated since then? How about other “committing” transactions?

– Validate against all the transactions committed or committing earlier, but finished their update phase after the starting time of the transaction.


UCDavis, ecs251Spring 2007 OCC - Parallel ValidationOCC - Parallel Validation




…..

difference: against themselves as well

abcacbbacbcacabcbacommitting

ab ba



OCC - PVOCC - PV




…..


UCDavis, ecs251Spring 2007 OCCOCC

the scheme is called optimistic because the likelihood of two transactions conflicting is low

a transaction proceeds without restriction until the closeTransaction (no waiting, therefore no deadlock)

it is then checked to see whether it has come into conflict with other transactions

when a conflict arises, a transaction is aborted each transaction has three phases

•


UCDavis, ecs251Spring 2007 Validation of transactionsValidation of transactions

We use the read-write conflict rules – to ensure a particular transaction is serially equivalent with respect to all

other overlapping transactions each transaction is given a transaction number when it starts validation

(the number is kept if it commits) the rules ensure serializability of transaction Tv (transaction being

validated) with respect to transaction Ti

Tv Ti Rule

write read 1. Ti must not read objects written by Tv

read write 2. Tv must not read objects written by Ti

write write 3. Ti must not write objects written by Tv and

Tv must not write objects written by Ti •

forward

backward


UCDavis, ecs251Spring 2007 OCC: OCC:

Optimistic Concurrency ControlOptimistic Concurrency Control


Validation

logging

Concurrency??Security?? Semantic Conflict detection

Intrusion detection

Abort conflict resolution


UCDavis, ecs251Spring 2007 AFSAFS

State-ful clients and servers. Caching the files to clients.

– File close ==> check-in the changes. How to maintain consistency?

– Using “Callback” in v2/3

openread

applications

invalidate and re-cache



Other Applications??Other Applications??

In what situations, the optimistic approach might be better than the traditional locking approach?


UCDavis, ecs251Spring 2007 Special CasesSpecial Cases

Long-life transactions– ???

Read-only transactions– Maybe a very common case– Die versus Kill



Multi-VersionsMulti-Versions

Data update history for every object. Every version has a logical timestamp




X

Y

time




X

Y

Real Time InitialValue




X

Y

Real Time InitialValue



MV -- Global VTSMV -- Global VTS

X

Y

Virtual Time InitialValue



Real-Only TransactionReal-Only Transaction

How to make sure that ROT will never be aborted?




X

Y




C


X

Y




Deciding the right “GTS”Deciding the right “GTS”



Deciding the right “GTS”Deciding the right “GTS” Get the latest committed version # from

“every object” (we have to know the Read Set in advance or maybe we will be aborted at most ONCE)

Choose the “smallest” # as the GTS for this read-only transaction?



Inactive ObjectInactive Object



Distributed OCCDistributed OCC

Distributed Files systems


UCDavis, ecs251Spring 2007 local OCC on 1 server: local OCC on 1 server:

Optimistic Concurrency ControlOptimistic Concurrency Control Execute theTransaction

Validation

logging

Abort conflict resolution

TR-setW-set

TR-setW-set

TR-setW-set

TR-setW-set

TR-setW-set


2PC


UCDavis, ecs251Spring 2007 DOCCDOCC

[tID 22]R-setW-set

[tID 05]R-setW-set

[tID 17]R-setW-set

[tID 67]R-setW-set

[tID 34]R-setW-set


Transaction-ID: tIDValidation-Order-ID: vID

Server X:

Server Y:

What is the issue here?

[tID 05]R-setW-set

[tID 34]R-setW-set

[tID 17]R-setW-set

[tID 67]R-setW-set

[tID 22]R-setW-set


[vID 03] [vID 05] [vID 06]

[vID 11] [vID 12] [vID 16]


UCDavis, ecs251Spring 2007 DOCCDOCC

[tID 22]R-setW-set

[tID 05]R-setW-set

[tID 17]R-setW-set

[tID 67]R-setW-set

[tID 34]R-setW-set


Transaction-ID: tIDValidation-Order-ID: vID

Server X:

Server Y:

Local serializable, but not global serializable!!

[tID 05]R-setW-set

[tID 34]R-setW-set

[tID 17]R-setW-set

[tID 67]R-setW-set

[tID 22]R-setW-set


[vID 03] [vID 05] [vID 06]

[vID 11] [vID 12] [vID 16]


UCDavis, ecs251Spring 2007 Distribited OCCDistribited OCC

How to extend OCC to a distributed system?– distributed 3 phases: working, validation, and

writing– how to coordinate?


UCDavis, ecs251Spring 2007 Distributed OCCDistributed OCC

Coordinator

Server Server Server Server Server…..

How to assign “consistent” transaction # to thesame global transaction?

OCC OCC OCC OCC OCC

What is the problem?

CoordinatorCoordinator


UCDavis, ecs251Spring 2007 Maximum Validation IDMaximum Validation ID

Coordinator

Server Server Server Server Server…..

CoordinatorCoordinator

mvID: the largest validation-ID being assigned on a local server!!

[mvID] [mvID] [mvID] [mvID] [mvID]


UCDavis, ecs251Spring 2007 Getting the vID Right!!Getting the vID Right!!

C S– What is the current value of [mvID]?

S C– Answer

C S– C chooses a value (max{mvIDi} + delta)

S C– success or not

C S– validation start if all succeed.



ReadingsReadings

OCC (Kung-Robinson) DMV-OCC

Documents

UCDavis, ecs251 Spring 2007 04/17/2007Transactions1 Operating System Models ecs251 Spring 2007: Operating System Models #2: Transactions Dr. S. Felix