Atomic RMI: A Distributed Transactional Memory Framework

Abstract

This paper presents Atomic RMI, a distributed transactional memory framework that supports the control flow model of execution. Atomic RMI extends Java RMI with distributed transactions that can run on many Java virtual machines located on different network nodes. Our system employs SVA, a fully-pessimistic concurrency control algorithm that provides exclusive access to shared objects and supports rollback and fault tolerance. SVA is capable of achieving a relatively high level of parallelism by interweaving transactions that access the same objects and by making transactions that do not share objects independent of one another. It also allows any operations within transactions, including irrevocable ones, like system calls, and provides an unobtrusive API. Our evaluation shows that in most cases Atomic RMI performs better than fine grained mutual-exclusion and read/write locking mechanisms. Atomic RMI also performs better than an optimistic transactional memory in environments with high contention and a high ratio of write operations, while being competitive otherwise.

Proving Opacity of Transactional Memory with Early Release

“…[14,20,8,4,23,26]), but systems with early release cannot satisfy the definition of opacity, even if they produce no histories with inconsistent views. Our proposition to show that histories with early release can be seen as indistinguishable from opaque histories via the application of decomposition means that safety is not traded for efficiency in TM systems with early release if transactions that release early never abort.…”

“…On the other hand systems that employ early release gain a significant improvement in performance (e.g. [23,26]). …”

Hybrid Transactional Replication: State-Machine and Deferred-Update Replication Combined

“…This is done by comparing the updates sets of the already committed updating transactions (stored in the Log variable), with the readset of the committing transaction. If none of the sets intersect, the transaction commits, the state modification it produced are made visible (lines [45][46][47][48], and the response is returned to the client (line 19). Otherwise the transaction is rolled back and restarted (line 24).…”

“…For clarity, we make several simplifications. Firstly, we use a single global (reentrant) lock to synchronize operations on LC (lines 22,45,46), Log (lines 8 and 47) and the accesses to transactional objects (lines 28 and 48). Secondly, we allow Log to grow indefinitely.…”

“…Note that HTR features two sets of functions/procedures facilitating execution of a transaction (i.e., read and write operations on shared objects) and managing the control flow of the transaction (i.e., procedures used to commit, rollback or retry the transaction). One set of functions/procedures is used by transactions executed in the DU mode (lines [31][32][33][34][35][36][37][38][39][40][41][42][43][44][45][46][47][48][49] and one is used by transactions executed in the SM mode (lines 74-91).…”