High-Performance Parallel Database Processing and Grid Databases- P9

High-Performance Parallel Database Processing and Grid Databases- P9: Parallel databases are database systems that are implemented on parallel computingplatforms. Therefore, high-performance query processing focuses on queryprocessing, including database queries and transactions, that makes use of parallelismtechniques applied to an underlying parallel computing platform in order toachieve high performance.
Nội dung trích xuất từ tài liệu:
High-Performance Parallel Database Processing and Grid Databases- P9380 Chapter 13 Replica Management in Grids 4. If the originator site decides to commit the transaction, it updates the TS.SID (at metadata service). The TS is increased to a new maximum, and SID points to the originator. The local timestamp of the site is also increased to match the TS of the Grid middleware. 5. Other replica sites in the partition (participants) also follow the same proce- dure if they decide to commit, i.e., the SID is set to the respective participant and the local timestamp is set to match the new TS at middleware. But the SID points to the originator and the local timestamp is not increased for any site that decides to locally abort the write transaction. 6. The number and detail of sites participating in the contingency update pro- cess are updated in the log. This is an important step, because the number of sites being updated does not form a quorum. Thus, after the partitioning has been repaired, the log is used to propagate updates to additional sites that will form a quorum. Once the quorum has been formed, normal GRAP operation can resume. Figure 13.6 is explained as follows. The quorum is collected for the data item tobe written (line 1). If the network is not partitioned and the collected quorum (Q a )is less than the required write quorum (Q w ) (line 2), the transaction is aborted. Butif the collected quorum is less than the required write quorum and the network ispartitioned (line 3), then the protocol works under the contingency quorum, thatis, the actual collected quorum. The maximum local timestamp at the partitionwhere the transaction is submitted and the maximum timestamp at the Grid (forthe respective replica) are obtained. If both the maximum values do not match,then the transaction is aborted (line 4). This implies that the partition does nothave the latest replica. If both timestamps match (line 5) but the originator decidesto abort (line 6), then the global transaction will abort. If the originator decides to commit (line 7), then the transaction can continuethe execution. For each site in the originator’s partition (line 8), the middleware’stimestamp is increased to a new maximum. The new site ID (SID) for theoriginator is set to point toward itself (line 9), which reflects that the originatordecided to commit, and contains the latest replica. The local timestamp of theoriginator is also increased to a new maximum to match the Grid middleware’stimestamp. Since the site is working under a contingency quorum, the site ID isadded in the log. If the participant site decides to commit (line 10), then the SID pointer is setto point toward itself, because that participant will also have the latest copy of thereplica and the local timestamp of the participant is set to match with the origina-tor’s maximum value. The site ID of the participant is also added to the log. But ifthe participant decides to abort its cohort (line 11), then the SID pointer points tothe originator and the local timestamp is unchanged. This ensures that the partic-ipant points to the latest replica of the data item. Since the participant decided toabort, it is not necessary to add the site ID to the log file. The contingency GRAP helps in executing transactions even in the case of mul-tiple partitioning. The partition that has the latest copy of the replica can continue. 13.4 Handling Multiple Partitioning 381It acts as a combination of quorum consensus protocol and primary copy protocol.The difference is that it updates all sites in the partition, not only a single site. Gridmiddleware’s metadata service helps to find the most up-to-date copy of the replica.13.4.2 Comparison of Replica ManagementProtocolsBased on the update mechanism, replication synchronization protocols can broadlybe classified into two categories: (i) synchronous, also known as eager replication,and (ii) asynchronous, also known as lazy replication. Synchronous replicationupdates all replicas of the data object as a single transaction. An asynchronousreplication protocol updates only one replica of the data, and the changes are prop-agated to other replicas later (lazily). Synchronous protocols ensure strict consistency among replicated data, but adisadvantage is that they are slow and computationally expensive, as many mes-sages are to be sent in the network. The response time of asynchronous replicationprotocols is less, compared with synchronous protocols, as they update the dataonly at one site. Asynchronous protocols do not guarantee strict consistency ofdata at distributed replica sites. The choice of a synchronous or an asynchronous replica protocol is a trade-offbetween strict consistency and the response time of the app ...