Article Preview
TopIntroduction
When using a centralized computing system, i.e. where data are stored on a central site (server) to receive all data modification requests from other sites (clients), usually unavailability and unreliability of data remain at the rendezvous. This is due to the fact that any time a hardware or a software failure of the central site, or even a connection problem or central site overload is likely to interrupt the access of client sites to centralized data (Nicoleta-Magdalena, 2011; Maarten and Andrew, 2016). However, to avoid this problem, the use of decentralized or distributed approach, whose data duplication (or replication) is the primary input to industrially produce data availability and reliability, is necessary (Özsu and Valduriez, 2011; Fatos et al., 2012).
Currently, the replication is the only technique that ensures the exchange of data between copies in distributed systems. As for the distributed databases, replication uses four strategies which result from the combination of two factors: “when” and “where”. The “when” factor specifies when updates are broadcasted to other copies; this can occur in real-time (synchronously/eager replication) or in near real-time (asynchronously/lazy replication), while the “where” factor indicate where updates occur, on a centralized site (primary copy/mono-master) or on decentralized sites (everywhere/multi-master), before being propagated to other copies. So, it results in four strategies, namely: eager centralized site, eager decentralized sites, lazy centralized site and lazy decentralized sites (Özsu and Valduriez, 2011; Fatos et al., 2012; Spaho et al., 2015). Once implemented, these strategies ensure data availability and reliability, each according to its technicality.
Nevertheless, nowadays, distributed systems, in general and distributed databases in particular, are experiencing a migration toward Peer-to-Peer (P2P) systems. In these last, each peer is supposed to store the entire database (Özsu and Valduriez, 2011), i.e. the database is fully replicated and participants (peers) are present or absent momentarily (Vu et al. 2009). However, in view of the above with respect to replication strategies, it is clear that it is the lazy or asynchronous strategy which is appropriate for P2P topology. It allows replicas of various sites to diverge for a given moment. So, updates propagation can be applicable on the present peers while the absent peers will remain with non-updated replicas in order to receive their updates when they become available again (Kituta et al., 2018).
But, in order to preserve data availability and reliability in replicated databases systems, replicas must reflect consistency at all times. However, to ensure strong copy consistency, the traditional technique is to avoid inconsistencies by implementing a synchronous or eager refresh algorithm which is specially Two-Phase-Commit (2PC) based (Özsu and Valduriez, 2011). Unfortunately for P2P replication this strategy is candidate to the major problem which is so that if there is an unavailable site during updates propagation by the master site, the transaction cannot commit. Beyond the unavailability of a site, concurrent execution makes the temporal complexity of a transaction very high. When there is an interlock between transactions that attempt to update the same copy, the wait time for the transaction to be performed is usually high and if it expires the transaction abort like if the site was unavailable.