Download - More About Transaction Management
![Page 1: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/1.jpg)
More About Transaction Management
Chapter 10
![Page 2: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/2.jpg)
Contents
• Transactions that Read Uncommitted Data
• View Serializability
• Resolving Deadlocks
• Distributed Databases
• Long-Duration Transactions
![Page 3: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/3.jpg)
The Dirty-Data Problem
Data is “dirty” if it has been written by a transaction that is not yet committed
Example 1: A written by T1 is a dirty data ,T2’s reading of A leaves the database with an inconsistent state
![Page 4: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/4.jpg)
T1 T2 A B
25 25
:l1(A);r1(A);
A:=A+100;
w1(A);l1(B);u1(A); 125
l2(A);r2(A);
A:=A*2;
w2(A);u2(A); 250
l2(B);Denied
r1(B);
Abort;u1(B); l2(B); u2(A); r2(B);
B:=B*2;
w2(B);u2(B) 50 T1 writes dirty data and then aborts
![Page 5: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/5.jpg)
Example 2:
T1 T2 T3 A B C
200 150 175 RT=0 RT=0 RT=0
WT=0 WT=0 WT=0
w2(B) WT=150
r1(B)
r2(A) RT=150
r3(C) RT=175
w2(C)
Abort WT=0
w3(A)) WT=175
T1 has read dirty data from T2 and must abort when T2 does
![Page 6: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/6.jpg)
Cascading Rollback
• When transaction T aborts,we must find each transaction U that read dirty data from T,abort U,find any transaction V that read dirty data from U,abort V,and so on
• Both a timestamp-based scheduler with a commit bit and a validation-based scheduler avoids cascading rollback
![Page 7: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/7.jpg)
Managing Rollbacks
• Strict Locking: A transaction must not release any write locks (or other locks, such as increment locks that allow values to be changed) until the transaction has either committed or aborted,and the commit or abort log record had been flushed to disk
• A schedule of transactions that obey the strict locking rule is called recoverable
![Page 8: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/8.jpg)
View Serializability
Conflict equivalent View equivalent
Conflict serializable View serializable
![Page 9: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/9.jpg)
Motivating example
Schedule QT1 T2 T3
Read(A)
Write(A)
Write(A)
Write(A)
![Page 10: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/10.jpg)
Same as
Q = r1(A) w2(A) w1(A) w3(A)
P(Q): T1 T2
T3
Not conflict serializable!
![Page 11: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/11.jpg)
But now compare Q to Ss, a serial schedule:
Q T1 T2 T3 Read(A)
Write(A) Write(A)
Write(A)
Ss T1 T2 T3 Read(A) Write(A) Write(A)
Write(A)
![Page 12: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/12.jpg)
• T1 reads same thing in Q, Ss
• T2, T3 read same thing (nothing?)
• After Q or Ss, DB is left in the same state
So what is wrong with Q?
![Page 13: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/13.jpg)
Definition Schedules S1,S2 are View Equivalent if:
(1) If in S1: wj(A) ri(A)
then in S2: wj(A) ri(A)
(2) If in S1: ri(A) reads initial DB value,
then in S2: ri(A) also reads initial DB value
(3) If in S1: Ti does last write on A,
then in S2: Ti also does last write on A
means “reads value produced”
![Page 14: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/14.jpg)
Definition
Schedule S1 is View Serializable if it is view equivalent to some serial schedule
![Page 15: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/15.jpg)
View Conflict
Serializable Serializable ?
• View Serializable Conflict Serializable
e.g., See Schedule Q
• Conflict Serializable View Serializable ?
![Page 16: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/16.jpg)
Lemma
Conflict Serializable View Serializable
Proof:
Swapping non-conflicting actions does not change what transactions read nor final DB state
![Page 17: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/17.jpg)
Venn Diagram
All schedules
View Serializable
ConflictSerializable
![Page 18: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/18.jpg)
Note: All view serializable schedules that are not conflict serializable, involve useless write
S = W2(A) … W3(A)….. no reads
![Page 19: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/19.jpg)
How do we test for view-serializability?
P(S) not good enough… (see schedule Q)
![Page 20: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/20.jpg)
• One problem: some swaps involving conflicting actions are OK… e.g.:
S = ….w2(A)……r1(A).... w3(A)… w4(A)
this action can moveif this write exists
![Page 21: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/21.jpg)
• Another problem: useless writes
S = …..W2(A)…….. W1(A)….. no A reads
![Page 22: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/22.jpg)
To check if S is View Serializable
(1) Add final transaction Tf that reads all DB (eliminates condition 3 of V-S definition)
E.g.: S = …..W1(A)…….. W2(A)… rf(A)
Last A write
?
add
![Page 23: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/23.jpg)
(2) Add initial transaction Tb that writes all DB (eliminates condition 2 of V-S definition)
E.g.: S = wb(A) ... r1(A) … w2(A) …
add
?
![Page 24: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/24.jpg)
(3) Create labeled precedence graph of S:(3a) If wi(A) rj(A) in S, add Ti Tj0
![Page 25: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/25.jpg)
(3b) For each wi(A) rj(A) doconsider each wk(A): [Tk Tb]
- If Ti Tb Tj Tf then insert Tk Ti some new p
Tj Tk
- If Ti =Tb Tj Tf then insert Tj Tk
- If Ti Tb Tj =Tf then insert Tk Ti
p
p
0
0
![Page 26: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/26.jpg)
(4) Check if there is some selection from each arc pair that turn s LP(S) into “acyclic” (if so, S is V-S)
![Page 27: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/27.jpg)
Example: check if Q is V-S:
Q = r1(A) w2(A) w1(A) w3(A)
Q’ = wb(A) r1(A) w2(A) w1(A) w3(A) rf(A)
T3
T2
T1
TfTb
rule 3(a)
0
0 0
0
rule 3(b)
0
0
rule 3(b)
LP(S) acyclic!!S is V-S
![Page 28: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/28.jpg)
Another example:
Z=wb(A) r1(A) w2(A) r3(A) w1(A) w3(A) rf(A)
T3
T2
T1
TfTb
00
01
1 0
0
00
do not pickthis one of “1” pair
LP(Z) acyclic, so Z is V-S(equivalent to Tb T1 T2 T3 Tf)
![Page 29: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/29.jpg)
Deadlocks
• Detection– Wait-for graph
• Prevention– Resource ordering– Timeout– Wait-die– Wound-wait
![Page 30: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/30.jpg)
Deadlock Detection
• Build Wait-For graph
• Use lock table structures
• Build incrementally or periodically
• When cycle found, rollback victim
T1
T3
T2
T6
T5
T4T7
![Page 31: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/31.jpg)
The Waits-For Graph In the waits-for graph there is an arc from
node(transactions) T to node U if there is some database element A such that
– U holds a lock on A– T is waiting for a lock on A,and– T cannot get a lock on A in its desired mode unless U
first releases its lock on A
• If there are no cycles in the waits-for graph, then each transaction can eventually complete
• If there is a cycle,then no transaction in the cycle can ever make progress,so there is a deadlock
![Page 32: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/32.jpg)
T1 T2 T3 T4
1)l1(A);r1(A)
2) l2(C);r2(C)
3) l3(B);r3(B)
4) l4(D);r4(D)
5) l2(A);Denied
6) l3(C);Denied
7) l4(A);Denied
8) l1(B);Denied
Beginning of a schedule with a deadlock
![Page 33: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/33.jpg)
3 2 1
4
Waits-for graph with a cycle caused by step(8)
3 2
Waits-for graph after T1 is rolled back
![Page 34: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/34.jpg)
Deadlock Prevention By Resource Ordering
• Order all elements A1, A2, …, An
• Every transaction is required to request locks on element in order.
Problem : Ordered lock requests not realistic in most cases
![Page 35: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/35.jpg)
Timeout
• If transaction waits more than L sec., roll it back!
• Simple scheme
• Hard to select L
![Page 36: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/36.jpg)
Wait-die
• Transactions given a timestamp when they arrive …. ts(Ti)
• Ti can only wait for Tj if ts(Ti)< ts(Tj) ...else die
![Page 37: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/37.jpg)
T1
(ts =10)
T2
(ts =20)
T3
(ts =25)
wait
wait
Example:
wait?
![Page 38: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/38.jpg)
Wound-wait
• Transactions given a timestamp when they arrive … ts(Ti)
• Ti wounds Tj if ts(Ti)< ts(Tj)
else Ti waits
“Wound”: Tj rolls back and gives lock to Ti
![Page 39: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/39.jpg)
T1
(ts =25)
T2
(ts =20)
T3
(ts =10)
wait
wait
Example:
wait
![Page 40: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/40.jpg)
Comparison of Deadlock Management
• Both wound-wait and wait-die are easier to implement than the waits-for graph method.
• The waits-for graph method aborts transactions only when there is a deadlock. However, either wound-wait or wait-die will sometimes roll back a transaction when there was no deadlock.
![Page 41: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/41.jpg)
Distributed Databases
data
DBMS
data
DBMS
data
DBMS
data
DBMS
Distributed Database System
![Page 42: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/42.jpg)
Advantages of a DDBS
• Speedy Queries by Parallelism
• Fault Tolerance by Data Replication
Increasing complexity and communication cost
![Page 43: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/43.jpg)
Data Distribution
• A bank with many branches
• A chain store with many individual stores
• A digital library with a consortium of universities
![Page 44: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/44.jpg)
Partitioning a relation among many sites
• Horizontal Decomposition
• Vertical Decomposition
![Page 45: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/45.jpg)
Parallelism: Pipelining• Example:
– T1 SELECT * FROM A WHERE cond
– T2 JOIN T1 and B
A B(with index)
select join
![Page 46: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/46.jpg)
Parallelism: Concurrent Operations• Example: SELECT * FROM A WHERE cond
A whereA.x < 10
select select
A where10 A.x < 20
select
A where20 A.x
merge data location isimportant...
![Page 47: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/47.jpg)
Join Processing• Example: JOIN A, B over attribute X
A1 A2 B1 B2
A.x < 10 A.x 10 B.x < 10 B.x 10
join strategy
![Page 48: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/48.jpg)
Join Processing• Example: JOIN A, B over attribute X
A1 A2 B1 B2
A.z < 10 A.z 10 B.z < 10 B.z 10
join strategy
![Page 49: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/49.jpg)
Data Replication
• Fault Tolerance
• Query Speedup
1. How to keep copies identical2. How to place copies properly3. How to handle communication failure
Some Problems
![Page 50: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/50.jpg)
Distributed Transactions
• Transaction components at a different site
• Each having the local scheduler and logger
![Page 51: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/51.jpg)
Distributed Commit --Executing Atomically
Office
Store1 Store i Store n…… ……
T0
T1 Ti Tn
MessageReport
![Page 52: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/52.jpg)
Two-Phase Commit
• Phase One: A coordinator component polls the components whether to commit or abort.
• Phase Two: The coordinator tells the components to commit if and only if all have expressed a willingness to commit.
![Page 53: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/53.jpg)
• Each site logs actions at that site but there is no global log.
• One site, called the coordinator, plays a special role in deciding whether or not the distributed transaction can commit.
• The two-phase commit protocol involves sending certain messages between the coordinator and the other sites. As each message is sent, it is logged at the sending site, to aid in recovery should be it necessary.
![Page 54: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/54.jpg)
ATMBank
Mainframe
An Example
![Page 55: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/55.jpg)
2PC: ATM Withdrawl
• Mainframe is coordinator
• Phase 1: ATM checks if money available; mainframe checks if account has funds (money and funds are “reserved”)
• Phase 2: ATM releases funds; mainframe debits account
![Page 56: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/56.jpg)
• Message in phase 1 of two-phase Commit
Coordinator
prepare
Ready or don‘t commit
Log <Prepare T>Log <Ready T> orLog <Don’t Commit T>
![Page 57: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/57.jpg)
Coordinator
Commit or abort
• Message in phase 2 of two-phase Commit
Log <Commit T> orLog <Abort T>
Log <Commit T> orLog <Abort T>
![Page 58: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/58.jpg)
Recovery of Distributed Transaction
• Last log record <Commit T>
• Last log record <Abort T>
• Last log record <Don’t commit T>
• Last log record <Ready T>
• No log record about T
![Page 59: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/59.jpg)
Coordinator Failure
• Wait for it to recover• Elect a new coordinator and poll all the sites (1) If some site has <Commit T>, commit T (2) If some site has <Abort T>, abort T (3) If no sites has <Commit T> or <Abort T> and at
least one site does not have <Ready T>, it is safe to abort T
(4) If there is no <Commit T> or <Abort T> but every surviving site has <Ready T>, must wait until the original coordinator recovers.
![Page 60: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/60.jpg)
Distributed Locking --Executing Serializably
• Locking Replicated Elements
• Centralized Lock Systems
• Primary-Copy Locking
• Global Locks From Local Locks
![Page 61: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/61.jpg)
A Cost Model for Distributed Locking Algorithms
• Assign one component of a transaction as the lock coordinator to gather all the locks it wants
• Lock data elements at its own site without messages.
• Lock data elements at the other site with three messages: requesting, granting and releasing.
![Page 62: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/62.jpg)
Locking Replicated Elements
Global locks on an element must be obtained through locks on one or more replicas.
![Page 63: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/63.jpg)
Centralized Lock Systems
• Designate one site , the lock site, to maintain a lock table for logical elements, whether or not they have copies at that site.
• When a transaction wants a lock on logical element X, it sends a request to the lock site, which grants or denies the lock, as appropriate.
![Page 64: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/64.jpg)
Primary-Copy Locking
• Each logical element X has one of its copies designated the “primary copy”.
• A transaction sends a request to the site of the primary copy of X to get a lock on X.
• The site of the primary copy maintains an entry for X in its lock table and grants or denies the request as appropriate.
![Page 65: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/65.jpg)
Global Locks From Local Locks
1. S is the number of copies of A that must be locked in shared mode in order for a transaction to have a global shared lock on A.
2. X is the number of copies of A that must be locked in exclusive mode in order for a transaction to have an exclusive lock on A.
![Page 66: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/66.jpg)
If 2x > n, there can be only one global exclusive lock on A.
If s+x >n, there cannot be both a global shared and global exclusive lock on A.
![Page 67: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/67.jpg)
• Read-Locks-One; Write-Locks-All (s=1,x=n)
Allowing a global read lock by obtaining a read lock on any copy, while allowing a global write lock only through write locks on every lock.
• Majority Locking (s=x=[(n+1)/2])
Require a read- or write-lock on a majority of the replicas to obtain a global lock.
![Page 68: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/68.jpg)
Long-Duration Transactions
A long transaction is one that takes too long to be allowed to hold locks that another transaction needs.
![Page 69: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/69.jpg)
Three Applications Involving Long Transactions
• Conventional DBMS Applications
• Design Systems
• Workflow Systems
![Page 70: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/70.jpg)
Workflow diagram for a traveler requesting expense reimbursement
Create travel report
ReserveMoney
Dept. authorization
Corporateapproval
Writecheck
Assistantapproval
StartA1 A2 A3
A4 A6
A5
available
Give to assistant
deny
denyAbort
Abortapprove
approve
Complete
approveAbort
Not enoughdeny
Abort
![Page 71: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/71.jpg)
Sagas
A saga is a collection of actions that together form a long-duration “ transaction”.
![Page 72: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/72.jpg)
Concurrency control for sagas is managed by two facilities
• Each action may be considered itself a (short) transaction, that when executed uses a conventional concurrency-control mechanism, such as locking.
• The overall transaction is managed through the mechanism of “compensating transactions”, which are inverses to the transactions at the nodes of the saga.
![Page 73: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/73.jpg)
Compensating Transactions
• To undo the effects of transactions on database state.
If a saga execution leads to the Abort node, then we roll back the saga by executing the compensating transactions for each executed action, in the reserve order of those actions.
![Page 74: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/74.jpg)
Exercises for Storage Management
• EX 2.2.1
• EX 2.2.2
• EX 2.6.7
• EX 3.2.2
• EX 3.3.4
• Ex 4.1.2
• Ex 4.3.1
• Ex 4.4.6
• Ex 5.2.7
• Ex 5.4.2
![Page 75: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/75.jpg)
Exercises for Query Processing
• Ex 6.1.6 (a)(d)• Ex 6.5.3• Ex 6.6.2• Ex 6.7.2• Ex 6.8.1
• Ex 7.1.3
• Ex 7.4.1 (c) , (d), (e),
• Ex 7.5.1
• Ex 7.6.1
• Ex 7.7.1 (b), (c)
![Page 76: More About Transaction Management](https://reader036.vdocuments.site/reader036/viewer/2022062407/56812aa8550346895d8e6e70/html5/thumbnails/76.jpg)
Exercises for Transaction Management
• Ex 8.2.7 (a), (e)
• Ex 8.3.3
• Ex 8.4.5 (c) , (d)
• Ex 9.2.1
• Ex 9.8.2 (b)
• Ex 9.9.1 (b) (c)• EX 10.1.2 (b) (c)• EX 10.2.1 (b) (c)• EX 10.3.1 (b) (c)• EX 10.6.2