1. Chapter 12 Grid Transaction Atomicity and Durability
12.1 Motivation
12.2 Grid Atomic Commit Protocol (Grid-ACP)
12.3 Handling Failure of Sites with Grid-ACP
12.4 Summary
12.5 Bibliographical Notes
12.6 Exercises

2. Grid Transaction Atomicity and Durability
‘A’ and ‘D’ of the ACID properties will be discussed
Two Phase Commit (2PC), 3PC and other variants used for homogeneous and heterogeneous distributed DBMS
These protocols are synchronous and tightly coupled
Need global management layer
This chapter will describe
An Atomic Commitment Protocol (ACP) for Grid environment
Effect of failure on transaction execution
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

3. 12.1. Motivation Homogeneous Distributed DBMS
2PC is the most widely accepted ACP
2PC is a consensus based protocol
It is a blocking protocol
Needs 3n messages for n participants and 3 rounds message exchange to reach a final decision
Coordinator’s broadcast to request vote
Participant’s vote message and
Coordinators broadcast of final decision
Heterogeneous / multi-DBMS
Mainly designed for shot-live / non-collaborative transactions
Design philosophy is bottom up
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

4. 12.1 Motivation (Cont’d) Grid DBMS
Synchronous communication is not practical
Dynamic in nature and hence design should be adaptable
Absence of global management layer presents extra design challenges
Multi-database employs redo, retry and compensate approach to achieve Atomic Commitment. These approaches cannot be implemented in Grid Database.
Grid database will need to access distributed data over the WWW
Traditionally most of the distributed data architecture uses distributed objects for communication, e.g. CORBA, which is not designed to work in WWW
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

5. 12.2 Grid Atomic Commit Protocol (Grid-ACP)
Grid-ACP uses semantic atomicity
Semantic atomicity can be defined as follows
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

6. 12.2 Grid-ACP (Cont’d) State Diagram of Grid-ACP
Pre-abort state is introduced for originator
Sleep and compensate state are introduced for participating sites
Participants will enter in sleep state after execution and can release all resources
Resources are released with waiting for global decision (Requirement of autonomous sites)
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

7. 12.2 Grid-ACP (Cont’d)
If the global decision is to abort after the site has entered in sleep state then local site starts the compensating process
If the compensating transaction commits successfully then the sub-transaction is semantically aborted
If global decision is to commit then the originator can directly commit
If global decision is to abort then originator enters pre-abort state
When all sub-transactions have successfully compensated only then the originator can enter abort state
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

8. 12.2 Grid-ACP (Cont’d) Grid-ACP Algorithm
Step-1) Global transaction is divided into sub-transactions and submitted to participating sites
Step-2) After successful completion, participants enter into sleep state and informs the originator. Necessary logs are recorded
Step-3) if all participants decided to go to ‘sleep’ then originator decides to commit and informs all participants. Even if one participant decided to abort then the decision is to abort and participants who decided to commit are informed to compensate
Step-4a) if the participant is in ‘sleep’ state and global decision is to commit; participants can directly go to commit state
Step-4b) if the participant is in ‘sleep’ state and global decision is to abort; compensating transactions must be executed. Abort is not possible as all resources such as locks are already released
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

9. 12.2 Grid-ACP (Cont’d) Originator’s algorithm for Grid-ACP
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

10. 12.2 Grid-ACP (Cont’d) Participant’s algorithm for Grid-ACP
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

11. 12.2 Grid-ACP (Cont’d) Early-Abort Grid-ACP
Step-3 of Grid-ACP can be modified to improve the performance
Originator can decide to abort as soon as it receives first abort rather than waiting for all responses
But with this strategy, abort response need to be sent to all participants
Participant’s algorithm will be same as Grid-ACP
Modified algorithm for the Originator for Grid-ACP is shown here:
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

12. 12.2 Grid-ACP (Cont’d) Example
Case 1 (Atomicity of single transaction): consider execution of same sub-transactions from previous chapter, equation 11.1 and 11.2
ST12 = r12(O1) r12(O2) w12(O1) C12
ST13 = w13(O3) C13
Sub-transactions running to successful completion:
Sub-transactions will execute and enter ‘sleep’ state
As both transactions decided to commit, the global decision is to commit
Originator decides to commit and informs participants
Participants directly enter in commit state
Any sub-transaction decides to abort:
Suppose ST13 decides to abort. This information is sent to originator and ST13 unilaterally decides to abort
The originator only need to inform the site 2 where ST12 is executing
As ST12 is in ‘Sleep’ state, it needs to execute the compensating transaction. If the compensating transaction is not successful it is resubmitted till it competes successfully to achieve semantic autonomy
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

13. 12.2 Grid-ACP (Cont’d) Example
Case 2 (Atomicity in presence of multiple transactions):
This scenario is more complicated as other transactions may have read from data written by the ‘sleeping’ transactions
Case of aborting transactions is discussed (if all transactions execute to successful completion then it is similar to case-1)
Consider global transactions from chapter-11:
T1 = r1(O1) r1(O2) w1(O3) w1(O1) C1
T2 = r2(O1) r2(O3) w2(O4) w2(O1) C2
Consider the following history:
H1 = r12(O1) r12(O2) w12(O1) S12 r22(O1) w22(O1) (S12 means ST is in sleep state)
In the above history, ST12 is waiting for final decision of T2
Suppose T2 decides to abort, then ST22 will also abort as it has read from ST12
This may lead to cascading abort, which is undesirable. But at the same time considering the autonomous behavior of grids this is unavoidable
As the preventive measure: (a) either a cap can be implemented to restrict number of cascades or (b) a conflicting global transaction may not be submitted
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

14. 12.2 Grid-ACP (Cont’d) Discussion
Grid-ACP deals with heterogeneity and autonomy between sites
Due to autonomy, synchronous communication is not possible
Algorithm has to pay a price of releasing resources (e.g. locks) unilaterally; as other transactions may read intermediate values
To avoid cascading aborts any transaction that reads from a ‘sleeping’ transaction should also not commit
Tradition DBMS solves this issue by using global DBMS
Grids cannot use global DBMS
‘Sleep’ state has two-fold purpose: a) acts as intermediate step before commit; b) can be used to cap the number of cascading aborts
‘Sleep’ state is defined in the interface and hence do not need any modification in the local transaction manager
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

15. 12.2 Grid-ACP (Cont’d) Message and Time Complexity Comparison Analysis
Following table summarizes message and time complexity of different ACP
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

16. 12.2 Grid-ACP (Cont’d) Correctness of Grid-ACP
An ACP ensures that all process reach a decision such that
AC1: All processes that reach a decision reach the same one
AC2: A process cannot reverse its decision after it has reached one
AC3: The commit decision can only be reached if all processes voted ‘yes’
AC4: If there are no failures and all processes voted ‘yes’, then the decision will be to commit
Condition AC2 is not valid for our discussion as Grid-ACP does not use ‘wait’ state
Lemma 12.1: If one sub-transaction aborts, all participating sub-transactions also abort.
Step-3 ensures that even if one participant decided to abort, the global decision is to abort. The abort decision is conveyed to all participants decided to ‘sleep’
If there is no communication failure, eventually all participants will receive the abort message and all sub-transactions will abort / semantically abort
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

17. 12.2 Grid-ACP (Cont’d)
Theorem 12.1: All participating sites reach the same final decision.
Part I (consistent commit): from Step-2 of the algorithm it is clear that participants execute autonomously
if local decision is to commit, the information is stored in local log and the sub-transaction goes to ‘sleep’ state
If the originator receives positive feedback from all sub-transactions, then it decides to commit and final decision is sent to all ‘sleeping’ sub-transactions
Participants do not need to do anything as all resources such as locks etc are already released. Transaction’s state is simply marked as ‘commit’.
Thus, consistent commit state is achieved by all participants
Part I (consistent abort): participants have to do more computation to achieve atomicity in case the global decision is to abort
Participants who decided to abort have already aborted unilaterally
From Lemma 12.1, it is clear that all participants who decided to commit now receive an ‘abort’ decision from the originator
As those participants who are in ‘sleep’ state have already release the locks they cannot be aborted. Hence compensating transactions are constructed using event-condition-action or compensation rules.
Compensating transactions are executed to achieve semantic atomicity (step-4b of the algorithm)
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

18. 12.2 Grid-ACP (Cont’d)
Compensating transactions must commit successfully to achieve semantic atomicity. If compensating transaction aborts, it must be re-submitted till it commits successfully (Line 2 of participant’s algorithm)
Thus all participant will eventually abort consistently if the global decision is to abort
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

19. 12.3 Handling Failure of Sites with Grid-ACP
Earlier Grid-ACP was discussed in a failure free environment
Failures are inevitable in real life. Grid-ACP is extended here to handle failures
Model for Storing Log Files at the Originator and Participating Sites
Traditional DBMS stores global logs
Grid DBMS cannot store global logs
In absence of global logs, data may become corrupted
Thus, local sites must store logs to recover from failures
Following figure shows the model for storing logs a various sites
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

20. 12.3 Handling Failure of Sites with Grid-ACP
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

21. 12.3 Handling Failure of Sites with Grid-ACP
Any site can act as participant or originator simultaneously
But for simplicity the figure distinguishes between the two
Information of active global transactions must be stored at participants’ as well as at the originator’s site
These logs are in addition to local logs
Implemented in the interface without any modification of local transaction managers
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

22. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Logs Required at the Originator Site
Global transaction active log: When a Global Transaction (GT) is submitted to Grid middleware, it generates globally unique identifier (GTID). Sub-transactions are created and the Global Transaction Active Log at the originator is updated with GTID
Global Transaction ready log: A global sub-transaction decides to commit and it informs the originator. If the sub-transaction is not the last cohort of the global transaction then Global Sub-transaction (GST) ready log is updated
Global Transaction Termination log: If last sub-transaction, along with all others decide to commit, then Global transaction termination log is updated for the respective GTID. If the global decision is to abort then the GT termination log is updated accordingly
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

23. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Logs Required at the Participant Site
Global sub-transaction active log:
As soon as the participant receives the sub-transaction, it becomes active and the sub-transaction is added in the GST Active log. When the transaction executes successfully and enters ‘sleep’ state, GST Active log is updated
Global sub-transaction termination log:
If the GST has to abort, it can do so unilaterally and GST termination log is updated. Otherwise when a global decision is received, then the GST termination log is updated
Participants do not need a ready log; this can be figured out from the combination of GST active and GST termination log
The ‘sleep’ state is updated in the active log, which indicates that the local decision is to commit the sub-transaction, hence the ready state
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

24. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Failure Recovery Algorithm for Grid-ACP
Sites may fail anytime during transaction execution
Various combination is possible: a) participant failure b) originator failure c) combination of two
Recovery procedure can handle failure while GT is executing in different states
Participant Recovery Procedure:
Step-1: Restart the participating DBMS.
Step-2: Recover local transactions by using information stored in the log. Local transactions access only single database site. Hence, local transactions can be recovered using centralised database system’s techniques.
Step-3: The participating site then checks in Global sub-transaction active log, whether it is executing sub-transaction of any global transaction.
Step-3A: If the site does not have any cohort of global transactions, then the site can recover independently by using local logs.
Step-3B: If the site is executing local sub-transactions of any global transactions, the originator site of the respective global transaction is informed. The site is then in a global recovery mode and normal access to the site is blocked until the recovery process is completed.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

25. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Step 3B Case-I
Participating site failed in running state: The sub-transaction is aborted, the GTID from Global sub-transaction active log is removed, ‘abort’ is appended in the Global sub-transaction termination log and the originator is informed of the decision
Step 3B Case-II
Participating site failed during compensate state: Participant failed after the global decision was received but before the compensation was successfully executed. Hence the sub-transaction must be semantically aborted. After recovery, if the GST termination log contains abort but GTID still exists in GST active log, then the participant knows it failed during compensate state. The compensating transaction is then rerun to completion. After successful compensation, GTID is removed from Global sub-transaction active log and acknowledgement is sent to the originator.
Step 3B Case-III
Participating site failed during sleep state: The participant in this state may not proceed unless it receives the decision from the originator. If GTID exists in the GST active log and no decision (commit or abort) could be found in the GST termination log regarding that GTID, then the participant knows that it failed during sleep state
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

26. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Case-III A
The GT termination log at originator contains commit: All other participants decided to commit. The failed participant also decided to commit as it was in ‘Sleep’ state. The originator replies with ‘commit’, the participant recovers and updates the GST termination log and removes GTID from GST active log.
Case-III B
The GT termination log at originator contains abort: the failed participant decided to commit but some other site must have decided to abort hence the final decision was to abort. The originator replies with ‘abort’ and the participant executes the compensating transaction. The GST termination log is then appended with ‘abort’ and the GTID is removed from the GST active log.
Case-III C
The GT is active (i.e. GT termination log has no information on transaction termination): If the GT is active, this implies that the originator is still waiting for the decision of other participants. The originator replies with ‘active’ and the participant can safely recover to the state where it failed i.e. sleep. No new entry in the participant’s log is required.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

27. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Case-III D
The GT termination log at originator contains pre-abort: This indicates the global decision to abort has been made and the originator is waiting for acknowledgements. If ‘abort’ is not found in the GST termination log at the participant, then it appends ‘abort’ in GST termination log. The participant should then execute the compensation rules and acknowledge the abortion of sub-transaction and remove the GTID from the GST active log.
The originator makes the final decision as to when all sub-transactions of the global transaction have ready entry in the GST ready log or any of the sub-transactions decide to abort
Step-4:Decision is made depending on the message that the participant receives in step-2 or step-3 from the originator. Participants’ logs are updated accordingly.
Step-5: The participating DBMS regains normal operations and starts accepting external requests.
Step-6: The participant’s recovery process is terminated.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

28. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Figure-1: Recovery algorithm of Grid-ACP for participant site
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

29. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Figure-1: Recovery algorithm of Grid-ACP for participant site
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

30. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Description of figure 1:
The algorithm first checks whether the site could recover locally, i.e. if no active sub-transactions could be found at the participant (line (1) of Figure 1, step-2 of the recovery procedure). If the participant had any active sub-transaction at the time of failure (line (2)), it checks the state of global sub-transaction. If the sub-transaction executing at the participant is in ‘running’ state (line (3), step-3B (case-I)) the decision is to abort the sub-transaction and the originator is informed. If the sub-transaction was in ‘compensate’ state during failure (line (4), step-3B (case-II)) then the compensating transaction is rerun to completion. If the sub-transaction was in ‘sleep’ state during failure (line (5), step-3B (case-III)) then the participant checks the status of the originator before making any decision. The originator could be in commit (line (6)), abort/ pre-abort ((line (7)) or active state (line (8)).
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

31. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Originator Recovery Procedure:
Step-1: Restart the originator site and restore the values from the log.
Step-2: Determine the status of outstanding sub-transactions executing in multiple participants
Step-2 Case I: The originator is in running state (sub-transaction running at originator is active): If the sub-transaction of the global transaction executing at the originator is active during the failure, the originator decides to abort, informs all participants to abort and appends ‘abort’ in GT termination log.
Step-2 Case II: The originator is in wait state (sub-transaction executing at the originator has successfully executed but waiting for response of other participants), i.e. GTID can be found in GT active log and no entry regarding the GTID in GT termination log. Number of ‘ready’ entries in the GST ready log is also less than the number of sub-transactions. The originator checks the status of participants before taking the final decision
Case II A: If all the participating sub-transactions for the corresponding global transaction are in running state, then the originator allows it to continue normally.
Case II B: If all the participating sub-transactions are in sleep state, then the originator decides to commit the global transaction. If some participants are running and some are in sleep state, then the originator records the information in the GST ready log for sub-transactions in ‘sleep’ state and lets the active sub-transactions complete normal execution.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

32. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Case II C: If any of the participating sites are either in ‘abort’ or ‘compensate’ state, then this signifies that the originator failed after the global decision to abort the transaction was made but could not update the log. The GT termination log is updated with ‘pre-abort’. The originator then informs all participants and it waits for acknowledgement from the participants.
Case II D: If the originator does not receive any status information from the participant, then originator assumes that the participating DBMS has failed and it is not operational. The recovery process is then blocked and it waits for the participant to recover. For performance reasons originator may be designed to wait only for pre-decided amount of time, i.e. a timeout period is fixed. The originator starts the abort procedure if the participant does not recover in the specified timeout period.
Step-2 Case III: The originator is in commit state, i.e. ‘commit’ entry found in GT termination log, but the global transaction is still active, i.e. GTID still exists in GT active log. Since the originator decided to commit, this indicates that all sub-transactions executed to successful completion. Hence all sub-transactions can only be in sleep or commit state.
Case III A: If the participant is in sleep state, then the originator instructs the participant about successful completion of the global transaction and updates the originator’s log. The participant then enters the commit state.
Case III B: If the participant is already in commit state then the originator just has to update its log.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

33. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
After the response is sent to all participants, the GTID is removed from the GT active log. This case is also valid if the ‘commit’ entry is not found in the GT termination log, but the number of ‘ready’ entries in the GST ready log is equal to the number of executing sub-transactions.
Step-2 Case IV: The originator is in pre-abort/abort state, i.e. ‘pre-abort’ or ‘abort’ entry found in the GT termination log. Since the originator decided to abort, this indicates that any of the sub-transactions must have decided to abort. If the originator is in ‘abort’ state, then all participants must be in ‘abort’ state. Since the originator enters the ‘abort’ state only after receiving all acknowledgements.
If the originator is in pre-‘abort’ state, then it is waiting for acknowledgement from some of the participants. Thus the participants can be either in ‘sleep’ or ‘abort’ state.
Case IV A: If the participant is in ‘sleep’ state, it communicates ‘abort’ decision to the originator. The participant then sends an acknowledgement to the originator after successful execution of the compensation procedure.
Case IV B: If the participant is in ‘abort’ state, acknowledgement from the participant is updated in the originator site. When all acknowledgements are received from the participants, the originator moves from ‘pre-abort’ to ‘abort’ state and the GTID is removed from the GT active log.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

34. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Step-3: Depending on above-mentioned scenario, responses from all participants are collected. If all participants’ response was to commit, i.e. they are in ‘sleep’ state, then global decision is to commit, which is conveyed to all participants. If any of the participants decided to abort, then the global abort decision is conveyed to all participants. The GT termination log is updated accordingly.
Step-4: The global recovery process terminates.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

35. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Figure 2: Recovery algorithm of Grid-ACP for originator site
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

36. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Figure 2: Recovery algorithm of Grid-ACP for originator site
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

37. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Description of Figure 2:
If GTID is in GT active log and no termination decision is made (line (1)), then the global transaction is active and thus the abort procedure is commenced. If the termination log has a wait entry in the originator site and the transaction is active (line (2)), then the originator must check the status of sub-transactions executing at all participants. All sub-transactions of the global transaction could be active and running (line (3)); some or all of the sub-transactions can be in a sleep state (line (4) and line (5)); any of the sub-transaction can be in an abort or pre-abort state (line (6)); or there can be no reply from the participants (line (7)). If the GTID exists in the originator’s termination log and the state of the global transaction was ‘commit’ (line (8)), then the participants can be either in ‘commit’ or ‘sleep’ state.
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

38. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
If the failure occurred during the pre-abort state of the global transaction (line (9)), then participants can be in ‘sleep’ or ‘abort’ state. If the transaction was active and the termination log had abort entry (line (10)), then the site is recovered to its earlier state. The transaction enters in abort state only after receiving acknowledgements from all participants. This implies that the failure occurred after the global transaction was aborted, but before the GTID was removed from the active log. Thus GTID is removed from the active log after recovery (line (11)). Hence the pre-abort state is important in Grid-ACP. Pre-abort state acts as an intermediary state while the global transaction receives acknowledgement from all sub-transactions
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

39. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Comparison of Recovery Protocols
Recovery model in centralised DBMS
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

40. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Recovery model for DBMSs with global recovery manager (distributed DBMS and multidatabase)
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

41. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Recovery model for Grid database architecture
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

42. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Correctness of Recovery Algorithm
recovery protocol is correct if it maintains the consistency of data and resumes the database state before failure
Three possible combinations of failure are: (i) only participant site failure (ii) only originator site failure and (iii) originator and participant failure simultaneously
Transaction Submission Procedure:
The log is updated with a begin operation upon the transaction arrival. The global transaction is then subdivided into multiple logical sub-transactions. A transaction identifier along with sub-transaction identifier is also recorded in the active log.
The sub-transactions are then submitted to the respective database sites. A sub-transaction active log is updated at the participating site of the global transaction. The originator must wait if the sub-transaction cannot be submitted, i.e. if the participant is not operational.
The decision to commit or abort the global transaction is made after a response from all participants has been gathered (similar to 2PC, but the participants do not wait for the global decision). If all participants’ responses were positive, i.e. they are all in ‘sleep’ state, then the originator decides to commit, or else the decision is to abort. The decision is recorded in the global transaction termination log and all sites participating in this global transaction are informed
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

43. 12.3 Handling Failure of Sites with Grid-ACP (Cont’d)
Correctness
Lemma 12.2: The effect of only the committed transaction is reflected in all databases. Uncommitted data is not reflected either in the participant(s), or in the originator after failure recovery
Correctness of lemma can be proved with three different possibilities: Case I: Only Participant Site Failure, Case II: Only Originator Site Failure and Case III: Originator and Participant Fails simultaneously
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

44. 12.4 Summary Atomicity properties in Grid Databases is addressed
Describes the Grid-Atomic Commit Protocol for global transactions in absence of global management layer
Failure recovery procedure is discussed
D. Taniar, C.H.C. Leung, W. Rahayu, S. Goel: High-Performance Parallel Database Processing and Grid Databases, John Wiley & Sons, 2008

45. Continue to Chapter 13…