Cache Serializability: Reducing Inconsistency in Edge Transactions

Read-only caches are widely used in cloud infrastructures to reduce access latency and load on backend databases. Operators view coherent caches as impractical at genuinely large scale and many client-facing caches are updated in an asynchronous manner with best-effort pipelines. Existing solutions that support cache consistency are inapplicable to this scenario since they require a round trip to the database on every cache transaction. Existing incoherent cache technologies are oblivious to transactional data access, even if the backend database supports transactions. We propose T-Cache, a novel caching policy for read-only transactions in which inconsistency is tolerable (won't cause safety violations) but undesirable (has a cost). T-Cache improves cache consistency despite asynchronous and unreliable communication between the cache and the database. We define cache-serializability, a variant of serializability that is suitable for incoherent caches, and prove that with unbounded resources T-Cache implements this new specification. With limited resources, T-Cache allows the system manager to choose a trade-off between performance and consistency. Our evaluation shows that T-Cache detects many inconsistencies with only nominal overhead. We use synthetic workloads to demonstrate the efficacy of T-Cache when data accesses are clustered and its adaptive reaction to workload changes. With workloads based on the real-world topologies, T-Cache detects 43-70% of the inconsistencies and increases the rate of consistent transactions by 33-58%.Comment: Ittay Eyal, Ken Birman, Robbert van Renesse, "Cache Serializability: Reducing Inconsistency in Edge Transactions," Distributed Computing Systems (ICDCS), IEEE 35th International Conference on, June~29 2015--July~2 201

Maintaining consistency in distributed systems

In systems designed as assemblies of independently developed components, concurrent access to data or data structures normally arises within individual programs, and is controlled using mutual exclusion constructs, such as semaphores and monitors. Where data is persistent and/or sets of operation are related to one another, transactions or linearizability may be more appropriate. Systems that incorporate cooperative styles of distributed execution often replicate or distribute data within groups of components. In these cases, group oriented consistency properties must be maintained, and tools based on the virtual synchrony execution model greatly simplify the task confronting an application developer. All three styles of distributed computing are likely to be seen in future systems - often, within the same application. This leads us to propose an integrated approach that permits applications that use virtual synchrony with concurrent objects that respect a linearizability constraint, and vice versa. Transactional subsystems are treated as a special case of linearizability

An EVACS simulation with nested transactions

Documented here is the recent effort of the MISSION Kernel Team on an Extra-Vehicular Activity Control System (EVACS) simulation with nested transactions. The team has implemented the EVACS simulation along with a design for nested transactions. The EVACS simulation is a project wide aid to exploring Mission and Safety Critical (MASC) applications and their support software. For this effort it served as a trial scenario for demonstrating nested transactions and exercising the transaction support design. The EVACS simulation is a simulation of some aspects of the Extra-Vehicular Activity Control System, in particular, just the selection of communication frequencies. Its current definition is quite narrow, serving only as a starting point for prototyping purposes. (EVACS itself may be supplanted in a larger scenario of a lunar outpost with astronauts and a lunar rover.) Initially the simulation of frequency selection was written without consideration of nested transactions. This scenario was then modified to embed its processing in nested transactions. To simplify the prototyping effort, only two aspects of the general design for transaction support have been implemented: the basic architecture and state recovery. The simulation has been implemented in the programming language Smalltalk. It consists of three components: (1) a simulation support code which provides the framework for initiating, interacting and tracing the system; (2) the EVACS application code itself, including its calls upon nested transaction support; and (3) a transaction support code which implements the logic necessary for nested transactions. Each of these components deserves further description, but for now only the transaction support is discussed