Tài liệu High-Performance Parallel Database Processing and Grid Databases- P8 pptx

If two global transactions having more than oneactive subtransaction i.e., global-global conflict exist, then the global transaction sub-is added in all participating sites’ active transa

(2) The global transactions currently executing are added to a set, which stores

all active transactions The set of active transactions is represented as

Active Trans.

(3) The middleware appends a timestamp to every subtransaction of the global

transaction before submitting it to the corresponding database

(4) If there are two active global transactions that access more than one

database site simultaneously, this creates a potential threat that localdatabases may schedule the subtransactions in conflicting order Thesubtransactions are therefore executed strictly according to the timestampattached to the subtransaction Total-order is achieved by executing theconflicting subtransactions according to the timestamp

(5) When all subtransactions of any global transaction complete the execution

at all the sites, the transaction terminates and is removed from Active Trans

set (see details in Termination Phase).

Note: Active trans and Active Trans(DB) are different The former is the

set of currently active global transactions, and the latter is a function thattakes the database site as an argument and returns the set of active transac-tions running at that database site

Explanation of Figure 11.3. Line 1 of Figure 11.3 checks the number of transactions of the submitted transaction If there is only a single subtransaction,then the global transaction can start executing immediately The global transaction

sub-is added in the active set (line 2) and sub-is submitted immediately to the databasefor execution (line 3) If the global transaction has more than one subtransaction,that is, the transaction accesses more than one database site, then total-order must

be followed Hence, the timestamp must be appended to all subtransactions of theglobal transaction The global transaction is added in the active set (line 4) Globaltransactions having only one subtransaction are filtered out from the active set,

and the new set (Conflict Active trans) of the conflicting global transactions is

formed (line 5) Timestamps are then appended to all subtransactions of the globaltransaction (line 6 and line 7) If the global transaction being submitted conflictswith other active global transactions, it must be submitted to the participant site’s

queue to be executed in total-order Conflict of a submitted global transaction (T i)

with some other active global transaction (T j) (having more than one active transaction) is checked in line 8 If two global transactions having more than oneactive subtransaction (i.e., global-global conflict) exist, then the global transaction

sub-is added in all participating sites’ active transaction sets (Active Trans(DB i)) (line13) and the subtransactions are submitted to the participants’ queue (line 14), to

be strictly executed according to the total-order If the submitted global tion does not conflict with any other active global transaction (i.e., line 8 is true),then the global transaction is added in the active transaction set of all the partici-pant sites (line 10), and the subtransaction is immediately submitted for scheduling(line 11)

transac-Global transactions are said to be conflicting if two global transactions havemore than two active subtransactions executing in different participating sites

11.3 Grid Concurrency Control 331

Algorithm: Grid Concurrency Control Algorithm for the

submission phase

input T i : Transaction

var Active_trans: set of active transactions var Conflict_Active_trans: set of active transactions

that conflict with global transaction being submitted

var Database_accessed [Ti]: database sites being accessed

3. submit subtransaction to DBi else

Figure 11.3 Grid concurrency control algorithm for submission phase

simultaneously This is different from the definition of conflicting transaction indefinition 11.2 The use of these two terms will be easily distinguished by thecontext

Termination Phase

The global transaction is considered active until a response from all tions is received Because of the atomicity property of the transaction, the global

subtransac-transaction cannot reach a final decision (i.e., commit or abort) until it has received

a decision from all the subtransactions The steps of the transaction terminationphase are explained as follows:

(1) When any subtransaction finishes execution, the originator site of the global

transaction is informed

(2) Active transactions, conflicting active transactions, and databases accessed

(by the global transaction) set are adjusted to reflect the recent changes due

to completion of the subtransaction

(3) The site checks whether a completed subtransaction is the last

subtransac-tion of the global transacsubtransac-tion to terminate

(3a) If the subtransaction is not the last to terminate, then the

subtransac-tions waiting in the queue cannot be scheduled

(3b) If the subtransaction is the last subtransaction of the global transaction

to terminate, then other conflicting subtransactions can be scheduled.The subtransactions from the queue then follow the normal submis-sion steps as discussed in Figure 11.3

Explanation of Figure 11.4. The originator site of the global transaction isinformed after any subtransaction completes execution The global transaction,

Algorithm: Grid Concurrency Control Algorithm for

termination phase

input ST: subtransaction of T i at a site that completes

execution

1 Active_trans D (Active_trans - T i ) // removes the global transaction from active set of the site

2 Conflict_Active_trans D (Conflict_Active_trans - T i )

3 Database_accessed [T i] D (Database_accessed [T i ] - DB k ) // the database where the subtransaction committed is removed from the set of database being accessed

by the global transaction

4 if(Database_accessed [Ti]) D φ //subtransaction was last cohort of GT Ti

5 resubmit subtransactions from queue for execution //from Figure 11.3

11.3 Grid Concurrency Control 333

T i, is then removed from the active transaction’s set (line 1) This follows theearlier assumption that a global transaction can have only one subtransactionrunning at any site at any particular time The conflicting active transaction’sset is also adjusted accordingly (line 2) The database site where the subtrans-action is completed is removed from the database accessed set (line 3) If thecompleted subtransaction is the last subtransaction of the global transaction,that is, the database accessed set is empty (line 4), other waiting subtransactions

in the queue are submitted for execution (line 5) The normal transactionsubmission procedure from Figure 11.3 is followed thereafter If the completedsubtransaction is not the last subtransaction, then the queue is unaffected(line 6)

Taking the same scenario as the earlier example, consider that global transactions

T1 and T2 are submitted in quick succession Since both the transactions need toaccess data from more than one site, they are forwarded to the middleware to checkthe metadata service and form subtransactions (eq 11.1, 11.2, 11.3, and 11.4)(step 1 of the GCC protocol) As data from multiple sites are to be accessed, the

transactions are added in the Active Trans set (step 2 of the GCC protocol) Since

subtransactions (eq 11.1 and 11.2) belong to the same global transaction, T1, themiddleware appends same timestamp to both of them, say, timestamp D 1 (step 3

of the protocol) Similarly, subtransactions (eq 11.3 and 11.4) belong to T2, hencethe same timestamp is appended to both of them, say, timestamp D 2 (step 3 of theprotocol)

By looking at equation 11.5, we note that history produced at the database site

DB2schedules the subtransaction of the global transaction T1before the

subtrans-action of T2(the history in equation 11.5 is serial, but it does not matter as long as

H2 is serializable, with serialization order T1 T2because the timestamp attached

to T1by the middleware is less than T2) Execution of equation 11.6 will be

pro-hibited by line 14 (or step 4) of the algorithm, because T1and T2are conflicting

global transactions and the serialization order is T2 T1, which does not followthe timestamp sequence

Hence, schedules H2 and H3 will be corrected by the GCC protocol asfollows:

11.3.5 Comparison with Traditional Concurrency Control Protocols

Homogeneous distributed concurrency control protocols may be lock-based,timestamp-based, or hybrid protocols The following discusses the lock-basedprotocol only, but the arguments hold for other protocols as well

The homogeneous distributed concurrency control protocols can be broadly

classified as (i / centralized and (ii) distributed The lock manager and the global

lock table are situated at a central site in a centralized protocol The flow of trol (sequence diagram) for centralized concurrency control protocols in distributedDBMS (e.g., centralized two-phase locking) is shown in Figure 11.5 All the globalinformation is stored in a central site, which makes the central site a hotspot andprone to failure To overcome the limitations of central management, a distributedconcurrency protocol is used in distributed DBMSs The flow of control messages

con-is shown in Figure 11.6 for dcon-istributed concurrency control protocols (e.g., dcon-is-tributed two-phase locking)

dis-Release lock request

Operation decision

Coordinator site (typically where the transaction is submitted)

Central site managing global information (e.g global lock table)

All participating

sites (1,2…n)

Lock request Lock granted

Operation command

Figure 11.5 Operations of a general centralized locking protocol (e.g., centralized two-phase locking) in homogeneous distributed DBMS

Operation command embedded with lock request

Coordinator site (typically where the transaction is submitted)

All participating sites

(1,2,…n)

Participant’s image of global information

Operation End of operation

Release lock request

Figure 11.6 Operations of a general distributed locking protocol (e.g., decentralized two-phase locking) in homogeneous distributed DBMS

11.3 Grid Concurrency Control 335

MDBS Reply

Forward final decision

to the originator

Final decision

Talk to participant depending

on its local protocol

Operation request embedded with global information

Originator site (wherethe transaction

is submitted)

Multidatabase management system (global management layer)

All participants

(1,2,…n)

Check with multi-DBMS layer if required

Figure 11.7 Operations of a general multi-DBMS protocol

Forward final decision to the originator Final decision

Forward operation request

to participants Operation request

Originator site (where the transactionis submitted)

Grid Middleware services (metadata and time stamp services for this purpose)

All participants

(1,2,…n)

Figure 11.8 Operations of GCC protocol

Figure 11.7 shows the sequence of operations for heterogeneous distributedDBMS (e.g., multidatabase systems) Figure 11.8 shows the sequence ofoperations for the GCC protocol and highlights that the middleware’s function

is very lightweight in a Grid environment, as it acts only as the rerouting nodefor the global transaction (specifically from correctness perspective), unlike allother architectures All other figures (Figs 11.5–11.7) have a global image of thedata and have more communication with the sites It could be noted that the finaldecision in Figure 11.8 runs in a straight line from the participants to the originatorvia the middleware; this shows that there is no processing at the middlewareand it acts only as a forwarding node Conversely, Figure 11.7 shows a time lagafter receiving the responses from the participants and before forwarding it tothe originator, as the multi-DBMS layer has to map the responses in a protocolunderstandable to the originator

The term “coordinator” is used in Figures 11.5 and 11.6 and “originator” inFigures 11.7 and 11.8 In both cases, the sites are where the global transaction

is submitted But the reason to distinguish between the two terms is that inFigures 11.5 and 11.6 the site also acts as the coordinator of the global transaction,while in Figures 11.7 and 11.8, because of site autonomy, the site acts only as theoriginator of the global transaction But Figure 11.7 has far more communicationcompared with Figure 11.8, with the multi-DBMS layer, as it stores and processesall the global information

A Grid-serializable schedule is considered correct in the Grid environment fordatabase systems A concurrency control protocol conforming to theorem 11.1 isGrid-serializable, and is thus correct Hence, to show the correctness of the GCCprotocol, any schedule produced by the GCC protocol has the Grid-serializabilityproperty Proposition 11.1 states the assumption that each DBMS can correctlyschedule the transactions (local transactions and global subtransactions) submitted

to its site

Proposition 11.1: All local transactions and global subtransactions submitted to

any local scheduler are scheduled in serializable order

Because of the autonomy of sites, local schedulers cannot communicate witheach other, and because of architectural limitations, the global scheduler cannot

be implemented in a Grid environment Because of the lack of communicationamong the local schedulers and the absence of a global scheduler, it becomesdifficult to maintain consistency of the data Thus the execution of global sub-transactions at local database sites must be handled in such a way that data consis-tency is maintained The additional requirement for Grid-serializability is stated inproposition 11.2

Proposition 11.2: Any two global transactions having more than one

subtransac-tion actively executing simultaneously must follow total-order

Based on propositions 11.1 and 11.2, the following theorem shows that allschedules produced by GCC protocol are Grid-serializable

Theorem 11.2: Every schedule produced by GCC protocol is Grid-serializable.

Proof: The types of possible schedules produced by the GCC are identified first,and then it can be shown that the schedules are Grid-serializable Global transac-tions are broadly classified in two categories:

11.4 Correctness of GCC Protocol 337

(a) Global transactions having only one subtransaction: Global transactions

having a single subtransaction can be scheduled immediately and willalways either precede or follow any of the conflicting transactions becausethey execute only on a single site From proposition 11.1, local schedulerscan schedule the transaction in serializable order

(b) Global transactions having more than one subtransaction: Global

trans-actions having more than one subtransaction may come under one of thefollowing two cases:

(i) Although the global transaction has multiple subtransactions, it

con-flicts with other active global transactions at only a single site This

scenario is not a threat to data consistency, and thus the subtransactionscould be scheduled immediately (Fig 11.3, line 8) Local schedulerscan correctly schedule transactions in this case

(ii) The global transaction has multiple transactions and conflicts with

other global transactions at more than one site: Local schedulers

cannot schedule global transactions for this scenario Hence, theGCC protocol submits all subtransactions in the queue and thesesubtransactions are executed strictly according to the timestampattached at the Grid middleware This ensures that if a subtransaction

of any global transaction, GT i, precedes a subtransaction of any other

global transaction, GT j , at any site, then subtransactions of GT i will

precede subtransactions of GT jat all sites

Thus for all cases: a, b –i and b – ii schedule conflicting global transactions in such a way that if any global transaction, GT i, precedes any other global transac-

tion, GT j , at any site, then GT i precedes GT j at all sites The type of schedulesproduced by GCC protocol is thus identified Next, it is shown that these schedulesare Grid-serializable

To prove that schedules are Grid-serializable, the Grid-serializability graphmust be acyclic and global transactions must be in total-order Conflicts of thefollowing types may occur:

ž Conflict between local and local transactions The local scheduler is

respon-sible for scheduling local transactions Total-order is required only for ules where global subtransactions are involved From proposition 11.1, localschedulers can schedule transactions in serializable order

sched-ž Conflict between global transaction and local transaction A local

transac-tion executes only in one site The subtransactransac-tion of the global transactransac-tioncan only conflict with the local transaction in that site Thus the local trans-action and the subtransaction of global transaction are scheduled by the samescheduler From proposition 11.1, these are scheduled in serializable order.Total-order is also maintained, as only one local scheduler is involved in theserialization process

ž Conflict between global and global transactions Assume that an arc exists from GT i ! GT j at any site DB i It will be shown that an arc from

GT j ! GT i cannot exist in GCC GT j can either precede GT i at thedatabase site DBi or at any other database site DB n Suppose GT j precedes and conflicts with GT i at data site DB i This contradicts with

proposition 11.1 Thus GT j cannot precede GT i at DB i Suppose GT j precedes and conflicts with GT i at any other data site DB n If GT j precedes

GT i at any other site, then total-order is not followed and it contradictsproposition 11.2 Figure 11.3 (line 14) of the GCC protocol prevents theoccurrence of such a scenario Thus schedules produced by the GCC protocolare Grid-serializable

The concurrency control protocol helps to interleave operations of different actions while maintaining the consistency of data in the presence of multiple users.The GCC protocol has the following main features:

trans-(a) Concurrency control in a heterogeneous environment: The GCC protocol

does not need to store global information regarding participating sites; e.g.,

in traditional distributed DBMS, a global lock table stores information of alllocks being accessed by the global transaction But in the Grid environment,all database sites might not be using the same concurrency control strategy(e.g., locking protocol) In the GCC protocol, individual subtransactions arefree to execute the local concurrency control protocol of participating sites.The Grid middleware is used to monitor the execution order of the conflictingtransactions

(b) Reducing the load from the originating site: The centralized scheduling

scheme and decentralized consensus-based policies intend to delegate theoriginating site of the transaction as the coordinator Thus the coordinatorsite may become a bottleneck when a transaction has to access multiple sitessimultaneously The GCC protocol delegates the scheduling responsibility

to the respective sites where the data resides without compromising thecorrectness of the data, and thus prevents the coordinator from becomingthe bottleneck

(c) Reducing the number of messages in the internetwork: Centralized and

consensus-based decentralized scheduling schemes need to communicatewith the coordinator to achieve correct schedules The communicationincreases the number of messages in the system Messages are one ofthe most expensive items to handle in any distributed infrastructure TheGCC protocol has fewer messages moving across the network to achieveconcurrency

Since the GCC protocol implements total-order on global transactions, the flicting transactions will always proceed in one direction, thereby avoiding theproblem of distributed deadlocks Local deadlock management is the policy ofthe local database site Because of autonomy restrictions, external interference in

con-11.8 Exercises 339

the local policy is not possible Other concurrency control anomalies such as lostupdate, dirty read, and unrepeatable read are addressed at the local DBMS level.The above-mentioned features are due to the architectural requirement of theGrid But there is a serious architectural limitation of Grid architecture in con-currency control protocols Because of the inability to install a global scheduler,

it becomes difficult to monitor the execution of global subtransactions at ent database sites As a result, some valid interleaving of transactions cannot takeplace Thus the resultant schedule becomes stricter than required

Grids are evolving as a new distributed computing infrastructure Traditionaldistributed databases such as distributed database management systems andmultidatabase management systems make use of globally stored information forconcurrency control protocols Centralized or decentralized consensus-basedpolicies are mostly employed for these database systems The Grid architecturedoes not support the storage of global information such as global lock tables,global schedulers, etc Thus a new concurrency control protocol, called GCC, forGrid databases is needed

The GCC protocol has several advantages: It operates in a heterogeneous ronment; the load of the originator site is reduced compared with traditional dis-tributed databases; and the number of messages in the network is reduced But

envi-at the same time, because of the lack of global control and autonomy restrictions

of the Grid architecture, it is difficult to optimize the scheduling process In thischapter, the focus was the maintenance of data consistency during scheduling ofthe global transactions

Consistency and isolation are two of the ACID properties of transaction, which are

the focus of this chapter Most of the important work on concurrency control hasbeen mentioned in the Bibliographical Notes section at the end of Chapter 10 This

covers the work on parallel and grid transaction management by Brayner (DEXA 2001), Burger et al (BNCOD 1994), Colohan et al (VLDB 2005), 1993), Machado and Collet (DASFAA 1997), Wang et al (Parallel Computing 1997), and Wiekum and Hasse (VLDB J).

11.1 Explain how concurrency control helps to achieve the “C” and “I” of the ACID

properties.

11.2 Explain why individual serializable schedules in each site of the Grid environment

may not produce a serializable global schedule.

11.3 Explain the following terminologies:

explain how it solves the concurrency issues in the Grid.

11.5 Compare and contrast the difference between GCC and any other concurrency control

protocols (e.g., distributed databases and multidatabase systems).

11.6 Discuss why the number of messages in the internetwork using GCC is reduced in

comparison with other concurrency control protocols.

is unsuitable for a Grid database because communication among sites must be chronous, and the latter is unsuitable because sites in Grid databases are autonomousand cannot accept any functional/architectural changes due to external factors.The purpose of this chapter is twofold First, an ACP for a Grid database isdescribed, that is, atomicity in a Grid database is addressed Failures are unavoid-able, and hence in the latter part of the chapter the effect of failure on transactionexecution is discussed, including details of different types of logs stored in the origi-nator and participant sites The chapter is organized as follows Section 12.1 presentsthe motivation for addressing atomic commitment in Grid databases Section 12.2describes the Grid-atomic commit protocol (Grid-ACP) and proves the correctness

asyn-of the protocol The Grid-ACP is extended to handle site failures in Section 12.3,including the comparison of the Grid-ACP with centralized and distributed recoverymodels Correctness of the recovery protocol is also given

High-Performance Parallel Database Processing and Grid Databases,

by David Taniar, Clement Leung, Wenny Rahayu, and Sushant Goel Copyright  2008 John Wiley & Sons, Inc.

decision: (1) the coordinator broadcasts a request to vote, (2) participants replywith their vote, and (3) the coordinator broadcasts the decision Many variationsand optimizations have been proposed to increase the performance of 2PC Buthomogeneity and synchronous communication among sites is the basic assumptionbehind the original and other variants of 2PC Grid architecture is heterogeneousand autonomous; thus dependence on other sites and synchronous communicationbetween sites is not a valid assumption.

Multi/federated database systems are heterogeneous, and they have been sively studied during the last decade Multi/federated database systems are mostlystudied, designed, and optimized for short-lived and noncollaborative transactions.These database systems are designed in a bottom-up fashion, that is, the sys-tem designer knows the design requirements before the system is designed anddeployed On the other hand, a Grid database supports long-running collaborativetransactions Design requirements of Grid databases can vary rapidly as the system

exten-is more dynamic than the traditional dexten-istributed, multi/federated databases becausesites should be able to join and leave the Grid dynamically without modifications

to the database management systems In addition, multidatabase systems have theleverage of a global management layer known as a multidatabase managementsystem

The transaction models developed for long-running transactions were designedwith nested transaction structures Hence, these models are not suitable for thecollaborative environment of Grids To summarize, the following points are noted:

(1) ACPs designed for homogeneous and synchronous distributed database

sys-tems cannot be implemented in Grid databases because of architectural itations (Grid databases are heterogeneous and asynchronous)

lim-(2) Multidatabase systems, being heterogeneous and autonomous in nature, are

architecturally closer to the Grid environment But they enjoy the leverage

of a multidatabase management systems layer, which is absent in Grids.The multidatabase layer stores global information such as global lock table,global logs, etc Because of site autonomy, Grids cannot store global infor-mation

(3) A multidatabase employs redo, retry, and compensate approach for ACP.

Redo and retry cannot be implemented in a Grid environment becauseboth approaches make use of a global management layer The compensateapproach assumes that no other transaction should be serialized betweenthe compensated-for transaction and the compensation transaction This

is impossible to implement in Grids because of the lack of a top-layer

12.2 Grid Atomic Commit Protocol (Grid-ACP) 343

management system and autonomy restrictions of sites Grid databases need

to operate in a loosely coupled service-oriented architecture

Even from an architectural perspective (apart from a data consistency spective), it is difficult to implement traditional ACPs in Grid environment Griddatabases will access data from globally separated data sites via WWW Most

per-of the distributed data architecture uses distributed objects for communication,for example, CORBA CORBA has major limitations while operating on WWW.CORBA was not designed to work with HTTP, the standard web-based protocol.Thus there is a need to develop protocols that can be easily integrated into webservices

In this chapter, an ACP suitable for heterogeneous, autonomous, and chronous Grid databases is presented

The concept of compensating transactions is used in Grid-ACP The execution

of compensating transactions results in semantic atomicity Semantic atomicity is

Figure 12.1 shows the state diagram of the proposed grid-atomic commitment

pro-tocol (Grid-ACP) A pre-abort state is introduced in the originator, and two new states, the sleep and compensate states, are introduced in the participant’s state dia-

gram The subtransaction will enter the “sleep” state when it has finished executionand is ready to release all acquired resources such as locks on data items, comput-ing resources, etc Because of the autonomy restriction in Grids, all resources must

be released according to the participating site’s requirement and cannot wait forthe global decision Thus the “sleep” state is an indication to transaction managersthat the local subtransaction of the global transaction at the participating site hasdecided to commit But the global decision is not yet made At the time whenthe subtransaction enters into the “sleep” state, all computing and data resourcescan be released All sites are autonomous and thus cannot hold resources for anyexternal process

If any of the other participating sites decide to abort any cohort of the global

transaction, T i, the originator site informs all the participating sites (in “sleep”

State diagram of participating site

Figure 12.1 State diagram of Grid-ACP

state) of T i to start the compensation While the compensating transaction is cuting, the site is in the compensate state If the compensating transaction fails,

exe-it is re-executed until exe-it is completed successfully This raises the question as towhether the compensating transaction can keep on executing forever The answer

is “no,” because the compensating transaction is the logical inverse of the ted subtransaction Since the subtransaction decided to successfully commit andwas in the “sleep” state, its logical inverse must also eventually commit Once thecompensating transaction successfully commits, the subtransaction is semanticallyaborted

commit-If the global transaction decides to commit, it can directly enter into the mit state But if the global decision is to abort, the originator of the transactioncannot directly enter into the abort state The originator must be assured that allparticipants have successfully compensated, that is, semantically aborted, and thus

com-it enters in the pre-abort state After receiving confirmation that all sleeping

sub-transactions have been successfully aborted, the originator enters into the abortstate

The Grid-ACP algorithm is as follows:

(1) Based on the information available at the middleware, the global transaction

is divided into subtransactions and submitted to the participating databasesystems

(2) The sites are autonomous in nature; hence after executing their portion of

the subtransactions, participants go into the “sleep” state The participants

12.2 Grid Atomic Commit Protocol (Grid-ACP) 345

then inform the originator about the outcome of the subtransactions sary information is logged Details of log files are discussed in the followingsections

Neces-(3) The originator, after collecting responses from all participants, decides

whether or not to commit or to abort the global transaction If allparticipants decide to go into the “sleep” state, the decision is to commit,

or else the decision is to abort If the decision is to abort, the message issent only to those participants who are in the sleep state If the decision is

to commit, the decision is sent to all participants

(4) (a) If the participating site decides to commit and is in the “sleep” state and

the global decision is also to commit, the subtransaction can go directly

to the commit state because local and global decisions are the same

(b) If the participating site decides to commit and is in the “sleep” state, but

the final decision is to abort the global transaction, then the action, which is in the sleep state, must be aborted But, as mentionedearlier, when the local site enters the sleep state it releases all locks ondata items as well as all acquired resources This makes abortion of thetransaction impossible Hence, a compensating transaction must be exe-

subtrans-cuted to reverse all the changes, using compensation rules, to restore the

semantics of the database before executing the original subtransaction,

thereby achieving semantic autonomy If the compensating transaction

fails, it is resubmitted until it commits The compensating transactionmust eventually commit, as it is a logical inverse of the “sleeping” trans-action We are not defining the compensation rules as they are out of thescope of this study

Grid-ACP for the originator of the global transaction is shown in Figure 12.2.Grid-ACP for participants of the global transaction is shown in Figure 12.3

Algorithm: Originator’s algorithm for Grid-ACP

submit subtransactions to participants;

wait for response from all participants;

1 if all response to sleep

3 send global  commit to all participants;

else

5 send global  abort to participants, decided

to commit;

Figure 12.2 Originator’s algorithm for Grid-ACP

Algorithm: Participant’s algorithm for Grid-ACP

received subtransaction from originator

if participant decides to commit write sleep in log

send commit decision to originator

originator if decision is commit

write commit in participant log else if decision is abort

start compensating transaction for subtransaction

restart compensating transaction until it

commits

write commit for compensating transaction send acknowledgement to originator

else write commit for compensating transaction else if participant decides to abort

write abort in log send abort decision to originator

Figure 12.3 Participant’s algorithm for Grid-ACP

of those subtransactions that are still active and have not yet reached a decision

The participants’ algorithm for early-abort Grid-ACP will be same as Figure 12.3,

and hence the discussion of the participants’ algorithm is omitted for the sake

of brevity Figure 12.4 shows the modified algorithm of the originator for theearly-abort protocol

The originator in the Grid-ACP algorithm waits until response from all ticipating sites is received (line 1, Fig 12.2) Those participants who decided

par-to abort would not be affected by the originapar-tor’s decision Thus if the globaldecision is to abort the transaction, the decision is only sent to participants thathave decided to commit their subtransactions (and are in the “sleep” state) Thisstrategy may sometimes become computationally expensive, for example, say a

global transaction has n subtransactions Suppose the first subtransaction returns

an abort decision; then the final decision must be a global abort Although theglobal decision can be made from available information, the originator still has

12.2 Grid Atomic Commit Protocol (Grid-ACP) 347

Algorithm: algorithm for early-abort Grid-ACP

submit subtransactions to participants;

wait for response from participants;

1 if any response is abort

3 send global  abort to all participants;

else if all response to sleep then begin

6 send global  commit to all participants;

Figure 12.4 Originator’s algorithm for early-abort Grid-ACP

to wait for other (n1) decisions to arrive from the participants If all other

par-ticipants decided to commit their subtransactions, effectively the computation iswasted, first in completing the subtransactions and then in compensating the sub-transactions

The originator’s algorithm for the early-abort Grid-ACP can make the globaldecision as soon as the first abort decision from any participant is received (line 1,Fig 12.4) An abort message to all participant sites can be sent immediately (line 3,Fig 12.4), and the computation cost of other participants can be saved Thus theoverhead of compensation could also be reduced If the last decision instead ofthe first one that was received from the participants is “abort,” then the early-abortGrid-ACP reduces to a normal Grid-ACP because all the participants have alreadyfinished execution

EXAMPLE

Let us consider a simple example to demonstrate the working of Grid-ACP There is no subtransaction executing at the originator site in this case Consider the following cases:

Case 1 (atomicity of a single transaction): Considering the execution of subtransactions

of equations 11.1 and 11.2 from Chapter 11.

ST12D r12.O1/r12.O2 /w 12.O1/C12

ST13 D w 13.O3/C13

Subtransactions running to successful completion: Subtransactions will autonomously

execute and enter into the “sleep” state (step 2 of Grid-ACP and line 1 of Fig 12.3) Since

ST12and ST13 both decided to commit, the originator’s decision is to “commit,” which is communicated to the participants (step 3 of Grid-ACP and lines 1 to 3 of Fig 12.2) As the global decision matches with the local ones, both subtransactions update their state from

“sleep” to “commit” (step 4a of Grid-ACP, and else part of Fig 12.3).

Any subtransaction decides to abort: Suppose ST13 decides to abort The originator’s

decision will now be to abort the global transaction (lines 4 to 6 of Fig 12.2) ST13 has

unilaterally decided to abort, and the decision only needs to be sent to ST12 at site 2 Since

ST12decided to commit, it starts the compensating procedure (step 4b of Grid-ACP and

else if part of Fig 12.3) Since the compensating transaction nullifies the effect of the ST12 ,

it may be of the following form:

CT12(compensating transaction for global transaction 1 at site 2)

D w 12 (old value of O1 /

If CT12aborts, it is reexecuted to successful completion, so that it reflects that ST12 has aborted The acknowledgement is sent back to the originator.

Case 2 (atomicity in the presence of multiple transactions): Maintaining atomicity in

the presence of multiple transactions is more complicated, because of the fact that other transactions may have read the values written by the “sleeping” transaction If all the sub-

transactions execute to completion, then the execution is similar to case 1 Therefore, we only discuss the case of aborting transactions Consider global transactions, T1and T2 , from Chapter 11.

T1D r1.O1/r1.O2 /w 1.O3 /w 1.O1/C1

T2D r2.O1/r2.O3 /w 2.O4 /w 2.O1/C2

Consider the following history:

H1D r12.O1/r12.O2 /w 12.O1/S12r22.O1 /w 22.O1 /

.S12means ST12 is in sleep state)

In the above history H1, ST12 is waiting for the global decision of T2 Suppose the

global decision is to abort T2, then ST12must also abort Consequently, ST22 should also

abort, as it has read from ST12 This situation may lead to cascading aborts Considering the autonomous behavior of Grids, this may be an unavoidable situation If any database site implements a strict schedule, there will be no cascading aborts, but it is not in the control

of the middleware As a preventive measure, the following two options can be considered:

(a) After a transaction enters into “sleep” state, a ceiling or cap value can be defined to

restrict the number of cascading aborts.

(b) A conflicting global transaction may not be submitted to a conflicting site until the

originator has made the final decision on the already executing global transaction,

so that cascading aborts may be avoided.

The purpose of Grid-ACP and early-abort Grid-ACP is to deal with autonomy andheterogeneity between sites Because of autonomy, synchronous communicationbetween the originator and participants is not possible, and thus participants decide

to commit unilaterally Deciding to commit the transaction unilaterally and withoutconsulting the originator does not come without a cost The algorithm pays a pricefor releasing locks and resources early, which is unavoidable in an autonomousenvironment like the Grid If the transaction releases the resources early, thenother transactions may read the values written by this transaction To handle this

12.2 Grid Atomic Commit Protocol (Grid-ACP) 349

problem, traditional multidatabase systems implement a top layer of multidatabasemanagement system The top-layer management system enforces a criterion thatprevents execution of any other global transaction between the compensated-fortransaction and the compensating transaction

Implementation of a top-layer management system is not possible in Grids for

two reasons: (i / the autonomy of sites and (ii) the criterion becomes too

restric-tive in the Grid environment (heterogeneous) The absence of a global management

layer increases the chances of cascading aborts For example, any local transaction

LT i that reads data written by any global transaction T s in the sleep state cannot

decide to commit If T s has to abort from the sleep state, then the local transaction

LT i must also abort, thus having cascading aborts or compensating transactions.Hence, to avoid cascading aborts/compensation, any transaction that reads fromvalues written by a transaction that is in the sleep state must also not commit

until the “sleeping” transaction commits But, considering the heterogeneity and

autonomy properties of the Grid architecture, cascading aborts/compensations areunavoidable Thus the purpose of the “sleep” state becomes twofold First, it acts as

an intermediate step before the commit state to encounter autonomy of the tecture, and second, the “sleep” state can be used by the application to cap thenumber of cascading aborts

archi-Implementing the “sleep” state does not need any modification to the local

transaction manager module The “sleep” state is defined in the interface, and

hence no changes are required in any local modules Thus the autonomy of theindividual site is maintained

Analysis

The time and message complexity of the algorithm are described below

Time Complexity Analysis

The Grid-ACP needs two rounds of messages under normal conditions: (1) theparticipant sends its decision to commit/abort and (2) the decision of the originator

is communicated to participants This gives an impression of 2PC, but the state

of participants after sending the decision is different While 2PC enters in waitstate and holds all the resources, computing, and data, until the global decision

is received, Grid-ACP releases all resources after sending the local decision andenters into a “sleep” state

Message Complexity Analysis

Let the number of participants be n Considering that the originator sends the final

decision to all the sites, including those sites it has decided to abort, the number of

messages in each round is n Thus maximum number of messages required is 2n to

reach a consistent decision under normal conditions Early-abort Grid-ACP takes

Table 12.1 Message and time complexity of ACPs

Grid-ACP for early abort .i C n/, ith message is the abort decision 2

.i C n/ messages to reach a decision Where 1
i
n, the ith message received

is the abort decision from the subtransaction The early-abort Grid-ACP behaveslike a Grid-ACP if the last message received by the originator is the abort decision

If the global decision is to commit, then both protocols behave in a similar manner.Table 12.1 shows the message and time complexity of Grid-ACP and compares

it with 2PC and 3PC protocols

An atomic commitment algorithm ensures that all processes reach a decision suchthat:

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 be reached only if all processes voted “yes” AC4: If there are no failures and all processes voted “yes”, then the decision

will be to commit

Grid-ACP meets the requirements mentioned above Since the protocol does not

use the wait state for the participants, condition AC2 is not valid for our discussion AC1 is the main objective of the protocol AC3 and AC4 will be proved while AC1

is not required to send to those participants who decided to abort, because anyparticipant deciding to abort may abort its subtransactions unilaterally If there is

no communication failure, all sites will eventually receive the message and are in

a consistent state, that is, “abort” in this case

Theorem 12.1: All participating sites reach the same final decision.

12.3 Handling Failure of Sites with Grid-ACP 351 Proof: The theorem is proved in two parts: Part I for consistent commit and Part

II for consistent abort.

Part I: In this part, it is shown that when the global decision is to commit, all

participants commit From step 2 of the algorithm, it is clear that the participantsexecute autonomously If the local decision is to commit, the information is logged

in the stable storage and the subtransaction goes into the sleep state after sending

a message to the originator If the originator of the transaction finds a commitdecision in the response, it sends the final commit to all participants In this case,the participant is not required to perform any action, as all the resources werealready released when the participant entered into the “sleep” state The participantjust has to mark the migration of the transaction’s state from “sleep” to “commit.”

Part II: The participants have to do more computation to achieve atomicity

if the global decision is to abort In this part, it is shown that if the global sion is to abort, all participants decide to abort From lemma 12.1, it is clear thatall participants who decide to commit now receive an abort decision from theoriginator Those participants deciding to abort have already aborted their sub-transactions unilaterally Those subtransactions that have decided to commit havealready released locks on data items and cannot be aborted Hence, compensating

deci-transactions are constructed using the event-condition-action or the compensation rules These compensating transactions are then executed to achieve the semantic

atomicity (step 4b of the algorithm) To achieve semantic atomicity, the sating transaction must commit If the compensating transaction aborts for somereason, it is re-executed until it commits The compensating transaction must even-tually commit, as it is a logical inverse of a committed transaction This is shown inthe state diagram by a self-referring compensate state (Fig 12.1), and line 2 of theparticipant’s algorithm (Fig 12.3) Although the compensating transaction com-mits, the subtransaction semantically aborts Thus all the participants terminatewith a consistent decision

In an earlier section, ACP for Grid databases in a failure-free environment wasdiscussed Failures are inevitable in real life In this section, the earlier proposedGrid-ACP is extended to handle failures

12.3.1 Model for Storing Log Files at the Originator and Participating Sites

Traditional distributed databases store global logs for failure recovery Asdiscussed above, because of architectural limitations, Grid databases cannot storeglobal logs In the absence of global logs, distributed data can become corrupted.Thus the interface of the sites must contain information in local logs in order

to recover from these failures Figure 12.5 shows the model for storing logs atvarious sites

GT Active log GSTReady log

GST Active log

GST Termination log

GST Active log

GST Termination log Participating-site 2

Legend :

GT – Global Transaction GST – Global Subtransaction GTID – Global Transaction Identifier

Participating-site n

…

GST Active log

GST Termination log

Figure 12.5 Model for storing log information at originator and participant sites

Any site can act as an originator or as a participant simultaneously, but forpedagogical simplicity in Figure 12.5 the originator site is distinguished from theparticipant sites Figure 12.5 shows that the information for active global transac-tions must be stored at participants’ sites as well as at the originator site This loginformation is in addition to what is required by the sites to maintain local logs, and

is implemented in the interface without any modifications to the local transactionmanagers

The following logs are required at each originator site (Fig 12.5):

(1) Global transaction active log: When a global transaction is submitted to the

originator, it is forwarded to the Grid middleware, which generates a ally unique identifier (GTID) The global transaction (GT) is then dividedinto subtransactions depending on the different distributed databases it has

glob-to access Next, the global transaction active log at the originaglob-tor is updatedwith GTID Subtransactions are then submitted to respective database sites,and each database site is called a participant of the GT

(2) Global subtransaction ready log: After the subtransaction has finished

exe-cution at the participating site, the originator is informed about the decision

If the participant’s decision is to commit and the subtransaction is not the last

12.3 Handling Failure of Sites with Grid-ACP 353

cohort of the GT, then the global subtransaction (GST) ready log is updatedwith the subtransaction’s decision

(3) Global transaction termination log: If the last subtransaction decides to

commit along with all other subtransactions, then the originator also decides

to commit Global transaction termination log is updated for the respectiveGTID and sends the final decision to all participants If any of the subtrans-actions decided to abort, then the global decision is “abort” and the GTtermination log is accordingly updated

The following logs are required at each participating site (Fig 12.5):

(1) Global subtransaction active log: As soon as the participant receives the

sub-transaction, it becomes active The subtransaction is added in the GST active log If the subtransaction executes successfully, it enters into the “sleep” state

and the GST active log is updated

(2) Global subtransaction termination log: If the subtransaction decides to

abort, it can do so unilaterally, and hence the GST termination log is updated

immediately Otherwise, when the participant receives the global decision,the GST termination log is updated accordingly

A global transaction can have one or more subtransaction(s) Participants do notneed a ready log; this can be figured out from the combination of the GST activeand GST termination logs The “sleep” state is updated in the active log, whichindicates that the local decision is to commit the subtransaction Thus the readylog is not required for participants

Above in this chapter, various states of executing global transactions at the inator as well as at the participants’ sites were outlined (Fig 12.1) Sites mayfail in any state during transaction execution There could be different combi-nations of site failure, for example, failure of only the participants, failure ofonly the originator, and simultaneous failure of both participants and originator

orig-In this section, recovery procedures for participants as well as for the originator

are proposed The recovery procedure can handle failure of global transactionsexecuting in various states (from Fig 12.1) Recovery algorithms for the origina-tor and participants are discussed separately There are two important points tomake here, before we proceed First, without loss of generality, participants andoriginators are distinguished, and second, global logs are not available for Griddatabases

Participant Recovery Procedure

The participant’s recovery procedure is as follows

Step 1: Restart the participating DBMS

Step 2: Recover local transactions by using information stored in the log Local

transactions access only a single database site Hence, local transactionscan be recovered with the centralized database system’s techniques

Step 3: The participating site then checks in the global subtransaction active

log, whether it is executing a subtransaction 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 subtransactions of any global

transactions, the originator site of the respective global action is informed The site is then in a global recovery mode,and normal access to the site is blocked until the recoveryprocess is completed

trans-Case I Participating site failed in running state: The subtransaction is

aborted, the GTID from the global subtransaction active log is removed,

“abort” is appended to the global subtransaction termination log, and theoriginator is informed of the decision

Case II Participating site failed during compensate state: This implies

that the participant failed after the global decision was receivedbut before the compensation was successfully executed Hence, the

subtransaction must be semantically aborted After recovery, if the GST

termination log contains abort but GTID still exists in the GST activelog, then the participant knows it failed during the compensate state Thecompensating transaction is then rerun to completion After successfulcompensation, GTID is removed from the global subtransaction activelog and acknowledgment is sent to the originator

Case III Participating site failed during the 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) can be found in the GST termination log regarding that GTID, then the participant knows that it failed during the sleep state.

(1) The GT termination log at the originator contains commit:

This implies that while the participant failed, all the otherparticipants also decided to commit (the failed participant

also decided to commit, as it is in sleep state) The originator

replies with “commit,” the participant recovers and updatesthe GST termination log and removes GTID from GST activelog

(2) The GT termination log at the originator contains abort: This

implies that although the failed participant decided to mit, some other participant or the originator itself must have