synchronization chapter 6 part iii transactions. –most of the lecture notes are based on slides by...
TRANSCRIPT
– Most of the lecture notes are based on slides by Prof. Jalal Y. Kawash at Univ. of Calgary
– Some slides are from Prof. Steve Goddard at University Nebraska, Lincoln, Prof. Harandi, Prof. Hou, Prof. Gupta and Prof. Vaidya from University of Illinois, Prof. Kulkarni from Princeton University
– I have modified them and added new slides
Giving credit where credit is due:
CSCE455/855 Distributed Operating Systems
Transactions
• Example Transaction:
Transfer amount X from A to Bdebit(Account A; Amount X): A = A – X;
credit(Account B; Amount X): B = B + X;
• Either do the whole thing or nothing
ACID Properties – AC
• Atomicity: No intermediate results are observable
– To an external observer, T jumps from the initial state to the final state, or never leaves the initial state
• Consistency: T produces consistent results only, otherwise it aborts
– T fulfills the consistency constraints of the application, no violation of system invariants
ACID Properties – ID
• Isolation: T looks like it is the only program running
– Notice the looks like!
• Durability: T produces unforgettable by the system results
– T’s results become part of reality
Some Transaction Primitives
Examples of primitives for transactions.
Primitive 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, etc.
WRITE Write data to a file, a table, etc.
Transaction Types
• Flat Transactions
• Flat Transactions with Savepoints
• Chained Transactions
• Nested Transactions
• Distributed Transactions
• Multi-level Transactions
• Open Nested Transactions
• Long-lived Transactions
Flat Transactions – All or Nothing
• Simplest Type• Basic building block for organizing an
application into atomic actions• Encloses a program with brackets:
– BEGIN_TRANSACTION– END_TRANSACTIONAll that is between the brackets is performed or
nothing at all
• Strictly satisfies ACID
Flat Transactions – Limitations
• All-or-nothing is not always appropriate
• It is beneficial to commit partial results (violate atomicity)
• Trip Planning: commit part of a transaction
• Bulk Updates: can be expensive to undo all updates
Trip Planning
a) Transaction to reserve three flights commitsb) Transaction aborts when third flight is unavailable
BEGIN_TRANSACTION reserve LNK -> MSP; reserve MSP -> SEA; reserve SEA -> YVR;END_TRANSACTION
(a)
BEGIN_TRANSACTION reserve LNK -> MSP; reserve MSP -> SEA; reserve SEA -> YVR full =>ABORT_TRANSACTION (b)
Flat Transactions with SavePointsT:
BEGIN_TRANSACTION
S1
…
Sm
SAVEPOINT
Sm+1
…
…
END_TRANSACTION
Failure here
ROLLBACK
Flat Tw/o
SavePoint
W SavePoint
Nested Transactions – No D • They organize T actions into a hierarchy1. A nested T is a tree of T’s; sub-trees are flat or
nested2. Leaf T’s are flat3. Root T = top-level T; all other are subTs4. SubT can commit or roll back. Its commit will
not take effect unless the root commits5. When a subT rolls back, all its children are
rolled back• Satisfy ACI, not the D (except for top level)
Nested Transactions – Trip Planning
BEGIN_TRANSACTION
BEGIN_SUB
reserve LNK -> MSP;END_SUB
BEGIN_SUB
reserve MSP -> SEA;
END_SUB
BEGIN_SUB
reserve SEA -> YVR;
END_SUB
END_TRANSACTION
Failure here
Can Commit
Can Commit
Distributed Transactions
• A flat transaction that runs in a distributed environment:
– Visit several nodes in the system
• Distributed T: structure is determined by the distribution of data in the DS
• Nested T: structure is determined by the functional decomposition of the application
Achieving Atomicity (I)
• Private Workspace: – Change a copy of data, keeping original intact– COMMIT: copy changed data to original – ROLLBACK: discard copy
Private Workspace
a) The file index and disk blocks for a three-block fileb) The situation after a transaction has modified block 0 and appended block 3c) After committing
Achieving Atomicity (II)
• Writeahead Log:– Change original data, logging every change before
making it– COMMIT: leave changes– ROLLBACK: restore from log
Writeahead Log
a) A transactionb) – d) The log before each statement is executed
x = 0;
y = 0;
BEGIN_TRANSACTION;
x = x + 1;
y = y + 2
x = y * y;
END_TRANSACTION;
(a)
Log
[x = 0 / 1]
(b)
Log
[x = 0 / 1]
[y = 0 / 2]
(c)
Log
[x = 0 / 1]
[y = 0 / 2]
[x = 1 / 4]
(d)
Achieving Consistency & Isolation
• Concurrency Control: controlling the execution of concurrent Ts operating on shared data
• Consistency & Isolation: All Ts must appear as if they executed in some sequential order, one after another (Serializability)
Serializability
d) Possible schedules
BEGIN_TRANSACTION x = 0; x = x + 1;END_TRANSACTION
(a)
BEGIN_TRANSACTION x = 0; x = x + 2;END_TRANSACTION
(b)
BEGIN_TRANSACTION x = 0; x = x + 3;END_TRANSACTION
(c)
Schedule 1 x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3 Legal
Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; Legal
Schedule 3 x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3; Illegal
(d)
a) – c) Three transactions
Ts as Sequences of Reads and Writes
• Transaction = sequence of read and write operations
– Read of x returning 1 by T: rT(x)1
– Write to x a value 2 by T: wT(x)2
Ta
BEGIN_TRANSACTION x = 0;
x = x + 1;END_TRANSACTION
BT wa(x)0 ra(x) 0 wa(x)1ET
Conflicting Operations
• Two operations o1 and o2 conflict if:
– Both o1 and o2 are on the same data item, and
– At least one of o1 and o2 is a write
wa(x)0ra(x) 0wa(x)1
wb(x)0rb(x) 0wb(x)2
wc(x)0rc(x) 0wc(x)3
X
Concurrency Control Algorithms (CCA)
• CCA: order read and write operations– By using locks (critical sections)– By using timestamps
• Pessimistic CCA: Act conservatively so that nothing can go wrong
• Optimistic CCA: Act aggressively, if something goes wrong, abort
Using Locks
• For T to access (read or write) a data item x:– T requests a lock on x from the scheduler
• When T finishes accessing x:– T releases the lock
• Scheduler grants acquisitions & releases on locks so that serializability is guaranteed
• Locks:– Shared: can only read x– Exclusive: can read and write x
ExampleTa
x = 0x = x + 1
Tb
x = 0x = x + 2
Serializabilityx = 1 or 2 onlyAcquire x.lock
w(x)0Release x.lock
Acquire x.lockw(x)0Release x.lock
Acquire x.lockr(x)0Release x.lock
Acquire x.lockw(x)1Release x.lock Acquire x.lock
r(x)1Release x.lock
Acquire x.lockw(x)3Release x.lock
x = 3
2PL – Scheduler Rules
1. When sched receives operation oT(x)v:
a. If ((exists o’ holding a lock on x) & (o’ and o are conflicting))
• Delay o
1. Else grant a lock to o and pass o to the data manager
a. Sched never releases a lock for x granted for operation o, until data manager acks the completion of o
b. Once sched releases a lock for T, T cannot be granted another lock. If T tries to, abort it
2PL – Analysis • 2PL guarantees serializability
• BUT not every serializable schedule can be generated by 2PL
• 2PL can cause a deadlock, concurrency is reduced
BEGIN_TRANSACTION x = 0; x = x + 1;
x = 6END_TRANSACTION
(a)
BEGIN_TRANSACTION x = 0; x = x + 2;
x = 8END_TRANSACTION
(b)
BEGIN_TRANSACTION x = 0; x = x + 3;
x = 10;END_TRANSACTION
(c)
2PL – Discussion
• Strict 2PL can also lead to a deadlock– Use timeouts to preempt locks
• Strict 2PL advantages:– Acquisitions and releases can be done more easily, without
T’s knowledge– T always reads committed data avoid cascaded aborts
2PL – Discussion
• Strict 2PL can also lead to a deadlock– Use timeouts to preempt locks
• Strict 2PL advantages:– Acquisitions and releases can be done more easily, without
T’s knowledge– T always reads committed data avoid cascaded aborts
• Every 2PL (both versions) schedule is serializable• BUT not every serializable schedule can be generated
by 2PL (both versions)
Pessimistic Timestamp Ordering (PTO)• Each T has a timestamp, denoted T.ts• Each operation in T has same timestamp (T.ts)• Using Lamport’s or vector timestamps, all Ts have
unique timestamp values• If T.ts < T’.ts then T must appear before T’ in the
schedule• With each data item x, associate:
– x.wts : largest ts of any T that executed wT(x)v– x.rts : largest ts of any T that executed rT(x)v
• Update x.wts (resp. x.rts) whenever wT(x)v (resp. rT(x)v) occurs
PTO General Concept
• If T.ts < T’.ts then T must appear before T’ in the schedule
• Process transactions in a serial order
• Can use the same file, but must do it in order
• Therefore isolation is preserved
PTO – read operation
• When Sched receives rT(x)v operation:
– if T.ts < x.wts
\\T tries to read the past
reject rT(x)v
roll T back (assign T a new ts and restart)– if T.ts x.wts – (Do we need to compare T.ts with x.rts?)
execute rT(x)v
x.rts = max(x.rts , T.ts)
PTO – write operation
• When Sched receives wT(x)v operation:
– if (T.ts < x.rts) or (T.ts < x.wts)\\T tries to write in the past
reject wT(x)v roll T back (assign T a new ts and restart)
– else
execute wT(x)v
x.wts = T.ts
PTO – Analysis • Will PTO cause deadlock?
– PTO is deadlock-free
• Each PTO schedule is serializable• Not every serializable schedule is possible in
PTO• 2PL can produce schedules not possible under
PTO, and vice versaAll serializable
SchedulesAll PTO
Schedules
All 2PLSchedules
Optimistic Timestamp Ordering (OTO)• Each T does its changes to data (in its private
workspace)
• When done either commit or restart
• Each data item x has x.wts and x.rts, updated as before
When T needs to commit,Check x’s ts
If there is a conflict then restart
else commit
OTO (cont.)• Parallelism is maximized
– No waiting on locks– Inefficient when an abort is needed
• Pessimistic vs. Optimistic CCA– For instance, PTO vs. OTO ??
TO: Cascaded Aborts Problem
• For example the following run with transactions T1 and T2:– W1(x) R2(x) W2(y) R1(z), when can we commit T1 and T2? – W1(x) R2(x) W2(y) C2 R1(z) C1
– This could be produced by a TO scheduler
• T2 commits even though having read (i.e., R2(x)) from an uncomitted transaction– Answer: a scheduler can keep a list of other transactions each transaction
has read from, and not let a transaction commit before this list consists of only committed transactions
• Cascaded aborts still possible! – Answer: To avoid cascaded aborts, the scheduler can tag data written by
uncommitted transactions as dirty, and never let a read operation start on such a data item before it was untagged