Rethinking safe consistency in distributed object-oriented programming

Mirko Köhler,Pascal Weisenburger,Alessandro Margara,Guido Salvaneschi,Nafise Eskandani

doi:10.1145/3428256

Abstract

Large scale distributed systems require to embrace the trade off between consistency and availability, accepting lower levels of consistency to guarantee higher availability. Existing programming languages are, however, agnostic to this compromise, resulting in consistency guarantees that are the same for the whole application and are implicitly adopted from the middleware or hardcoded in configuration files. In this paper, we propose to integrate availability in the design of an object-oriented language, allowing developers to specify different consistency and isolation constraints in the same application at the granularity of single objects. We investigate how availability levels interact with object structure and define a type system that preserves correct program behavior. Our evaluation shows that our solution performs efficiently and improves the design of distributed applications.

Highlights

Replication is fundamental in large-scale distributed systems to improve data availability and data access latency
We propose ConSysT, a language where consistency and availability are integrated with the objectoriented programming model
In ConSysT, the availability level is attached to the bank account and all operations performed on the bank account have the same availability level

Summary

Introduction

Replication is fundamental in large-scale distributed systems to improve data availability and data access latency. By replicating data at multiple sites, distributed components can interact with the closest (e.g., local) replica without incurring the cost of remote data access. Synchronizing replicas to ensure a globally consistent view implies onerous performance costs that can hamper rather than improve availability and latency. For this reason, weakly consistent models have been widely adopted to limit synchronization overhead at the expense of correctness [Vogels 2009]. One option is to build the application on top of a highly consistent data store and accept the overhead of strong

Results

Discussion

Conclusion