Figure 13.1 Distributed transactions (a) Flat transaction (b) Nested ...

Figure 13.1

Distributed transactions (a) Flat transaction

(b) Nested transactions

M

X T

11

X Client

T

N

T1

Y

T

12

T

T

T Client

T

21

2

Y P

Z T

Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3

©Pearson Education 2001

22

1

Figure 13.2

Nested banking transaction X Client

T1

A

a.withdraw(10)

B

b.withdraw(20)

C

c.deposit(10)

D

d.deposit(20)

T T = openTransaction openSubTransaction a.withdraw(10); openSubTransaction b.withdraw(20); openSubTransaction c.deposit(10); openSubTransaction d.deposit(20); closeTransaction

Y T

2

Z T T


3 4


2

Figure 13.3

A distributed banking transaction coordinator join

openTransaction closeTransaction

A

. join

T Client

participant a.withdraw(4);

BranchX participant

b.withdraw(T, 3);

T = openTransaction a.withdraw(4); c.deposit(4); b.withdraw(3); d.deposit(3); closeTransaction

B join

BranchY participant

Note: the coordinator is in one of the servers, e.g. BranchX


b.withdraw(3);


C

c.deposit(4);

D

d.deposit(3);

BranchZ

3

Figure 13.4

Operations for two-phase commit protocol canCommit?(trans)→ Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote. doCommit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. doAbort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction. haveCommitted(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction. getDecision(trans) → Yes / No Call from participant to coordinator to ask for the decision on a transaction after it has voted Yes but has still had no reply after some delay. Used to recover from server crash or delayed messages.



4

Figure 13.5

The two-phase commit protocol Phase 1 (voting phase): 1. The coordinator sends a canCommit? request to each of the participants in the transaction. 2. When a participant receives a canCommit? request it replies with its vote (Yes or No) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vote is No the participant aborts immediately. Phase 2 (completion according to outcome of vote): 3. The coordinator collects the votes (including its own). (a)If there are no failures and all the votes are Yes the coordinator decides to commit the transaction and sends a doCommit request to each of the participants. (b)Otherwise the coordinator decides to abort the transaction and sends doAbort requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a doCommit or doAbort request from the coordinator. When a participant receives one of these messages it acts accordingly and in the case of commit, makes a haveCommitted call as confirmation to the coordinator.



5

Figure 13.6

Communication in two-phase commit protocol

Coordinator

Participant

step status

step

status

2

prepared to commit (uncertain)

4

committed

1 3

prepared to commit (waiting for votes) committed done

canCommit? Yes doCommit haveCommitted



6

Figure 13.7

Operations in coordinator for nested transactions openSubTransaction(trans) → subTrans Opens a new subtransaction whose parent is trans and returns a unique subtransaction identifier. getStatus(trans)→ committed, aborted, provisional Asks the coordinator to report on the status of the transaction trans. Returns values representing one of the following: committed, aborted, provisional.



7

Figure 13.8

Transaction T decides whether to commit T T1

T

2

abort (at M)

provisional commit (at X)

T

T

11

12

provisional commit (at N)

T 21

provisional commit (at N)

T

provisional commit (at P)

aborted (at Y)


22


8

Figure 13.9

Information held by coordinators of nested transactions: Coordinator Child of transaction transactions T T1, T2 T1 T11, T12 T2 T21, T22 T11 T12, T21 T22

Participant

Provisional commit list T1, T12 T1, T12

yes yes no (aborted) no (aborted) T12 but not T21 T21, T12 no (parent aborted) T22



Abort list T11, T2 T11 T2 T11

9

Figure 13.10

canCommit? for hierarchic two-phase commit protocol canCommit?(trans, subTrans) → Yes / No Call a coordinator to ask coordinator of child subtransaction whether it can commit a subtransaction subTrans. The first argument trans is the transaction identifier of top-level transaction. Participant replies with its vote Yes / No.

Figure 13.11

canCommit? for flat two-phase commit protocol canCommit?(trans, abortList) → Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participant replies with its vote Yes / No.



10

Figure 13.12

Interleavings of transactions U, V and W U

d.deposit(10)

V lock D b.deposit(10)

a.deposit(20)

W

lock A

lock B at Y

at X c.deposit(30) b.withdraw(30)

wait at Y

lock C at Z

c.withdraw(20)

wait at Z a.withdraw(20)



wait at X

11

Figure 13.13

Distributed deadlock

(a)

(b) W Held by

W Waits for

D

C

A X

Z Waits for

V Held by

Held by V

U B

U

Waits for

Held by Y



12

Figure 13.14

Local and global wait-for graphs local wait-for graph

T

local wait-for graph

U X


V

global deadlock detector T

T Y


U

V

13

Figure 13.15

Probes transmitted to detect deadlock W

W→ U → V → W

Held by

Waits for

Deadlock detected C A

Z Initiation

X

W

→

Waits for

U

→

W

V

V

U U

Held by Y


→

B


Waits for

14

Two probes initiated (a) initial situation

→ U

U→

T

→

V

T→

→ U

→

W V


W V

W

→


W

→

T → V

V

U

U

Waits for

T

U

V

→

W

T→

→

U

T

T

V

Waits for

T

W

Waits for

(b) detection initiated at object (c) detection initiated at object requested by T requested by W

W

Figure 13.16

W

Waits for

15

Figure 13.17

Probes travel downhill (a) V stores probe when U starts waiting (b) Probe is forwarded when V starts waiting W U→V V→ W

W

probe queue

V U →V

Waits for B


U →V

U

Waits for C

V U→V


probe queue

U Waits for B

16

Figure 13.18

Types of entry in a recovery file Type of entry

Description of contents of entry

Object

A value of an object.

Transaction identifier, transaction status (prepared, committed, Transaction status aborted) – and other status values used for the two-phase commit protocol. Intentions list

Transaction identifier and a sequence of intentions, each of which consists of , .



17

Figure 13.19

Log for banking service

P0 P1 P2 Object:A Object:B Object:C Object:A Object:B 100 200 300 80 220

P3 Trans:T prepared P0

P4 P5 P6 P7 Trans:T Object:C Object:B Trans:U committed 278 242 prepared P3 P4

Checkpoint


End of log


18

Figure 13.20

Shadow versions Map at start

Map when T commits A → P1 B → P2 C → P0"

A → P0 B → P0' C → P0" Version store

P0 100

P0' 200

P0" 300

P1 80

P2 220

P3 278

P4 242

Checkpoint



19

Figure 13.21 Trans:T prepared intentions list

Log with entries relating to two-phase commit protocol Coord’r:T • part’pant list: . . .

• Trans:T

Trans:U

•

committed prepared

• Part’pant:U Trans:U

Trans:U

Coord’r: . . . uncertain committed

intentions list



20

Figure 13.22 Role

Recovery of the two-phase commit protocol Status

Action of recovery manager

Coordinator

prepared

No decision had been reached before the server failed. It sends abortTransaction to all the servers in the participant list and adds the transaction status aborted in its recovery file. Same action for state aborted. If there is no participant list, the participants will eventually timeout and abort the transaction.

Coordinator

committed

A decision to commit had been reached before the server failed. It sends a doCommit to all the participants in its participant list (in case it had not done so before) and resumes the two-phase protocol at step 4 (Fig 13.5).

Participant

committed

The participant sends a haveCommitted message to the coordinator (in case this was not done before it failed). This will allow the coordinator to discard information about this transaction at the next checkpoint.

Participant

uncertain

The participant failed before it knew the outcome of the transaction. It cannot determine the status of the transaction until the coordinator informs it of the decision. It will send a getDecision to the coordinator to determine the status of the transaction. When it receives the reply it will commit or abort accordingly.

Participant

prepared

The participant has not yet voted and can abort the transaction.

Coordinator

done

No action is required.



21

Figure 13.23

Nested transactions top of stack T11 A1

T1 T

T12 T2


A11 A1

T1


A11

T11

A12 A11

A12

A2

A2

A12 T12

T2

22

Figure 13.1 Distributed transactions (a) Flat transaction (b) Nested ...

Figure 13.1 Distributed transactions (a) Flat transaction (b) Nested ...

Suggest Documents

Scheduling Closed-Nested Transactions in Distributed Transactional ...

A Flat Process Calculus for Nested Membrane

Compositional Nested Long Running Transactions

Integrity Checking for Nested Transactions

Serializability of Nested Transactions in

FIGURE 1 a) FIGURE 1 b - arXiv

Speculative Distributed Transaction Processing

Global Nested Transaction Management for ODMG ... - CiteSeerX

Safer Open-Nested Transactions Through Ownership

Figure B

Safe Open-Nested Transactions Through Ownership

Lock Inheritance in Nested Transactions 1

LNCS 3347 - A Nested Transaction Model for LDAP ... - Springer Link

A Nested Logit Model of Product and Transaction ... - Semantic Scholar

A Nested Logit Model of Product and Transaction

A Nested Transaction Model for Multilevel Secure Database ...

Distributed Transaction Routing in a Large Scale

A Nested Logit Model of Product and Transaction ... - Semantic Scholar

A Distributed Transaction Model for Read-Write

A Transaction Model for Active Distributed Object

Figure S1. A B C

A) B) Figure S1.

A Nested Transaction Mechanism for LOCUS ABSTRACT - CiteSeerX

A Concurrency Control Protocol for Nested Transaction s - UCR CS