Date post: | 22-Dec-2015 |
Category: |
Documents |
View: | 213 times |
Download: | 0 times |
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/
04/17/2007 Transactions 2
UCDavis, ecs251Spring 2007
TransactionTransaction
A sequence/program of operations {read, write} on a set of “shared” variables
04/17/2007 Transactions 3
UCDavis, ecs251Spring 2007
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,…
04/17/2007 Transactions 4
UCDavis, ecs251Spring 2007
Applications of TransactionsApplications of Transactions
Database/Information System Distributed Mobile computing Distributed File System Fault Tolerant computing
04/17/2007 Transactions 5
UCDavis, ecs251Spring 2007
Transaction Properties: ACIDTransaction Properties: ACID
Atomicity (all or nothing) Consistency (consistent state transition) Isolation (intermediate results) Durability (persistent)
04/17/2007 Transactions 6
UCDavis, ecs251Spring 2007
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…
04/17/2007 Transactions 7
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)
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
04/17/2007 Transactions 8
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 9
UCDavis, ecs251Spring 2007
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
Tb >> Tc >> Ta or “bca”
04/17/2007 Transactions 10
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 11
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 12
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 13
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 14
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 15
UCDavis, ecs251Spring 2007
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
a b cY
YY,Z
X
04/17/2007 Transactions 16
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.
04/17/2007 Transactions 17
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 18
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 19
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).
•
04/17/2007 Transactions 20
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
04/17/2007 Transactions 21
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
04/17/2007 Transactions 22
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.
04/17/2007 Transactions 23
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
04/17/2007 Transactions 24
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??
04/17/2007 Transactions 25
UCDavis, ecs251Spring 2007
(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)
04/17/2007 Transactions 26
UCDavis, ecs251Spring 2007
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)
04/17/2007 Transactions 27
UCDavis, ecs251Spring 2007
(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)
04/17/2007 Transactions 28
UCDavis, ecs251Spring 2007
(a)lock(Y)lock(X)R(X)W(X)R(Y)W(Y)unlock(X)unlock(Y)
(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(Y)lock(Z) R(Y)R(Z)W(Y)W(Z)unlock(Z)unlock(Y)
04/17/2007 Transactions 29
UCDavis, ecs251Spring 2007
(a)lock(X)R(X)W(X)Lock(Y)Unlock(x)R(Y)W(Y)unlock(Y)
(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(Y) R(Y)Lock(z)R(Z)W(Y)Unlock(Y)W(Z)unlock(Z)
04/17/2007 Transactions 30
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 31
UCDavis, ecs251Spring 2007 Two-Phase LockingTwo-Phase Locking
Two-phase locking.
04/17/2007 Transactions 32
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!!
04/17/2007 Transactions 33
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
04/17/2007 Transactions 34
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?
04/17/2007 Transactions 35
UCDavis, ecs251Spring 2007
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.
04/17/2007 Transactions 36
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
04/17/2007 Transactions 37
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)
04/17/2007 Transactions 38
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
04/17/2007 Transactions 39
UCDavis, ecs251Spring 2007TSstart
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))
04/17/2007 Transactions 40
UCDavis, ecs251Spring 2007TSstart
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
04/17/2007 Transactions 41
UCDavis, ecs251Spring 2007TSstart
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?
04/17/2007 Transactions 42
UCDavis, ecs251Spring 2007TSstart
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
04/17/2007 Transactions 43
UCDavis, ecs251Spring 2007TSstart
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
04/17/2007 Transactions 44
UCDavis, ecs251Spring 2007TSstart
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
04/17/2007 Transactions 45
UCDavis, ecs251Spring 2007TSstart
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
04/17/2007 Transactions 46
UCDavis, ecs251Spring 2007TSstart
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
04/17/2007 Transactions 47
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 48
UCDavis, ecs251Spring 2007
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”!
04/17/2007 Transactions 49
UCDavis, ecs251Spring 2007
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.
04/17/2007 Transactions 50
UCDavis, ecs251Spring 2007 OCC: OCC:
Optimistic Concurrency ControlOptimistic Concurrency Control
Execute theTransaction
Validation
logging
Commit or abort??
04/17/2007 Transactions 51
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.
04/17/2007 Transactions 52
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
04/17/2007 Transactions 53
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.
04/17/2007 Transactions 54
UCDavis, ecs251Spring 2007 How to Validate??How to Validate??
Execute theTransaction
Validation
logging
04/17/2007 Transactions 55
UCDavis, ecs251Spring 2007 How to Validate??How to Validate??
Assign the Transaction number– similar to the TSO, but until the beginning of the
validation phase.
04/17/2007 Transactions 56
UCDavis, ecs251Spring 2007 How to Validate??How to Validate??
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”
04/17/2007 Transactions 57
UCDavis, ecs251Spring 2007
Three Phases in OCCThree Phases in OCC
Working Validation Update
Starting Time of the Transaction Commit
04/17/2007 Transactions 58
UCDavis, ecs251Spring 2007 OCC transactionsOCC transactions
Earlier committedtransactions
Working Validation Update
T1
Tcurrent
Transactionbeing validated
T2
T3
Later activetransactions
active1
active2
04/17/2007 Transactions 59
UCDavis, ecs251Spring 2007 Which ones should we Which ones should we
consider?consider?
Earlier committedtransactions
Working Validation Update
T1
Tcurrent
Transactionbeing validated
T2
T3
Later activetransactions
active1
active2
04/17/2007 Transactions 60
UCDavis, ecs251Spring 2007
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
04/17/2007 Transactions 61
UCDavis, ecs251Spring 2007
Why not Write-Write conflicts?Why not Write-Write conflicts? WW conflicts:
– In OCC, all the writes are performed in one shot (atomically)!!
04/17/2007 Transactions 64
UCDavis, ecs251Spring 2007 (a)
validation
W(X)W(Z)
(b)validation
W(Y)W(X)
(c)
validation
W(Y)W(Z)
04/17/2007 Transactions 65
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;}
04/17/2007 Transactions 66
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
committed currentcommitted
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?
04/17/2007 Transactions 67
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).
04/17/2007 Transactions 68
UCDavis, ecs251Spring 2007 OCC - Serial ValidationOCC - Serial Validation
committed committing working/in progress
transaction numberbeing assigned
LatestCommittedtransaction
04/17/2007 Transactions 69
UCDavis, ecs251Spring 2007 Parallel ValidationParallel Validation
Can I validate multiple transactions at the same time?
04/17/2007 Transactions 70
UCDavis, ecs251Spring 2007
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.
04/17/2007 Transactions 71
UCDavis, ecs251Spring 2007 OCC - Parallel ValidationOCC - Parallel Validation
committed committing working/in progress
transaction numberbeing assigned
LatestCommittedtransaction
…..
difference: against themselves as well
abcacbbacbcacabcbacommitting
ab ba
04/17/2007 Transactions 72
UCDavis, ecs251Spring 2007
OCC - PVOCC - PV
committed committing working/in progress
transaction numberbeing assigned
LatestCommittedtransaction
…..
04/17/2007 Transactions 73
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
•
04/17/2007 Transactions 74
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
04/17/2007 Transactions 75
UCDavis, ecs251Spring 2007 OCC: OCC:
Optimistic Concurrency ControlOptimistic Concurrency Control
Execute theTransaction
Validation
logging
Concurrency??Security?? Semantic Conflict detection
Intrusion detection
Abort conflict resolution
04/17/2007 Transactions 76
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
04/17/2007 Transactions 77
UCDavis, ecs251Spring 2007
Other Applications??Other Applications??
In what situations, the optimistic approach might be better than the traditional locking approach?
04/17/2007 Transactions 78
UCDavis, ecs251Spring 2007 Special CasesSpecial Cases
Long-life transactions– ???
Read-only transactions– Maybe a very common case– Die versus Kill
04/17/2007 Transactions 79
UCDavis, ecs251Spring 2007
Multi-VersionsMulti-Versions
Data update history for every object. Every version has a logical timestamp
04/17/2007 Transactions 81
UCDavis, ecs251Spring 2007
Multi-VersionsMulti-Versions
X
Y
Real Time InitialValue
04/17/2007 Transactions 82
UCDavis, ecs251Spring 2007
Multi-VersionsMulti-Versions
X
Y
Real Time InitialValue
04/17/2007 Transactions 83
UCDavis, ecs251Spring 2007
MV -- Global VTSMV -- Global VTS
X
Y
Virtual Time InitialValue
04/17/2007 Transactions 84
UCDavis, ecs251Spring 2007
Real-Only TransactionReal-Only Transaction
How to make sure that ROT will never be aborted?
04/17/2007 Transactions 85
UCDavis, ecs251Spring 2007
MV -- Global VTSMV -- Global VTS
X
Y
Virtual Time InitialValue
04/17/2007 Transactions 86
UCDavis, ecs251Spring 2007
C
MV -- Global VTSMV -- Global VTS
X
Y
Virtual Time InitialValue
04/17/2007 Transactions 87
UCDavis, ecs251Spring 2007
Deciding the right “GTS”Deciding the right “GTS”
04/17/2007 Transactions 88
UCDavis, ecs251Spring 2007
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?
04/17/2007 Transactions 90
UCDavis, ecs251Spring 2007
Distributed OCCDistributed OCC
Distributed Files systems
04/17/2007 Transactions 91
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
committed currentcommitted
2PC
04/17/2007 Transactions 92
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
committed currentcommitted
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
committed currentcommitted
[vID 03] [vID 05] [vID 06]
[vID 11] [vID 12] [vID 16]
04/17/2007 Transactions 93
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
committed currentcommitted
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
committed currentcommitted
[vID 03] [vID 05] [vID 06]
[vID 11] [vID 12] [vID 16]
04/17/2007 Transactions 94
UCDavis, ecs251Spring 2007 Distribited OCCDistribited OCC
How to extend OCC to a distributed system?– distributed 3 phases: working, validation, and
writing– how to coordinate?
04/17/2007 Transactions 95
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
04/17/2007 Transactions 96
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]
04/17/2007 Transactions 97
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.