Hybrid Replication: State-Machine-Based and Deferred-Update Replication Schemes Combined

Abstract

Abstract-We propose a novel algorithm for hybrid transactional replication (HTR) of highly dependable services. It combines two schemes: a transaction is executed either optimistically by only one service replica in the deferred update mode (DU), or deterministically by all replicas in the state machine mode (SM); the choice is made by an oracle. The DU mode allows for parallelism and thus takes advantage of multicore hardware. In contrast to DU, the SM mode guarantees abort-free execution, so it is suitable for irrevocable operations and transactions generating high contention. For expressiveness, transactions can be discarded or retried on demand. We developed HTR-enabled Paxos STM, an object-based distributed transactional memory system, and evaluated it using several benchmarks: Bank, Distributed STMBench7, and Twitter Clone. We tested our system under various workloads and three oracle types: DU and SM, which execute all transactions in one mode, and Hybrid-tailored specifically for each benchmark-which selects a mode for each transaction dynamically based on various parameters. In all our tests, the Hybrid oracle is not worse than DU and SM and outperforms them when the number of replicas grows.

Self-tuning in Distributed Transactional Memory

“…The transaction dispatcher is a component present in several DTM platforms [10,5,26], and is in charge of determining whether the execution of a transaction should take place on the node that generated it, on a different one, or even by all nodes in the platform. This decision can be driven by different rationales, such as reducing data contention [26] or enhancing data locality [10,5,21].…”

“…The transaction dispatcher is a component present in several DTM platforms [10,5,26], and is in charge of determining whether the execution of a transaction should take place on the node that generated it, on a different one, or even by all nodes in the platform. This decision can be driven by different rationales, such as reducing data contention [26] or enhancing data locality [10,5,21]. In order to support the migration and execution of entire transactions at remote nodes, the transaction dispatching mechanism typically requires ad-hoc support at the DTM API layer in order to ensure proper encapsulation of the transaction logic, i.e., a function/procedure encoded in a programming language, and of its input parameters (using classic RPI mechanisms).…”

“…Recent research [26,38,39,40] has shown that transactional workloads are very heterogeneous and affected by so many variables that no-one-sizefits-all solution exists for the DTM configuration that guarantees optimal performance across all possible applications' workloads. To address this issue, a number of alternative solutions have been proposed to tackle the problem of self-tuning DTMs.…”

Self-Tuning Transactional Data Grids: The Cloud-TM Approach

“…Regarding the replication protocol, we are aware of only two solutions that encompass its self-tuning, namely HTR [12] and PolyCert [13]. In both, the most appropriate protocol to validate the transaction with is determined on a per-transaction basis.…”

“…However, the self-tuning of any other platforms' parameters is at least uncommon for commercial platforms (at least based on available documentation [9], [10]). On the other hand, academic solutions for self-tuning of cloud data stores [11], [12], [13] target individual platform's parameters, failing to capture the strong intertwining between them (e.g., the choice of the replication protocol is clearly dependent on the platform's scale and on the number of data replicas stored in the platform). The Cloud-TM platform, conversely, takes a unique approach to self-tuning, based on two principles:…”