# Distributed Transactions: Dissecting the Nightmare

**Authors:** Diego Didona, Rachid Guerraoui, Jingjing Wang, Willy Zwaenepoel

arXiv: 1803.06341 · 2018-03-19

## TL;DR

This paper investigates the fundamental limitations of distributed transactional storage systems, revealing that even read-only transactions face intrinsic constraints in speed and visibility, which explains the challenges in optimizing their performance.

## Contribution

It proves inherent limitations of distributed storage systems, showing that read-only transactions cannot be both fast and non-visible, clarifying why performance optimizations are difficult.

## Key findings

- Read-only transactions cannot be executed in a single round-trip.
- Fast read-only transactions must be visible, causing inherent server updates.
- These limitations explain the disappointing performance results in practice.

## Abstract

Many distributed storage systems are transactional and a lot of work has been devoted to optimizing their performance, especially the performance of read-only transactions that are considered the most frequent in practice. Yet, the results obtained so far are rather disappointing, and some of the design decisions seem contrived. This paper contributes to explaining this state of affairs by proving intrinsic limitations of transactional storage systems, even those that need not ensure strong consistency but only causality.   We first consider general storage systems where some transactions are read-only and some also involve write operations. We show that even read-only transactions cannot be "fast": their operations cannot be executed within one round-trip message exchange between a client seeking an object and the server storing it. We then consider systems (as sometimes implemented today) where all transactions are read-only, i.e., updates are performed as individual operations outside transactions. In this case, read-only transactions can indeed be "fast", but we prove that they need to be "visible". They induce inherent updates on the servers, which in turn impact their overall performance.

## Full text

_Full body text omitted from this summary view._ Fetch the complete paper as Markdown: https://tomesphere.com/paper/1803.06341/full.md

## Figures

23 figures with captions in the complete paper: https://tomesphere.com/paper/1803.06341/full.md

## References

39 references — full list in the complete paper: https://tomesphere.com/paper/1803.06341/full.md

---
Source: https://tomesphere.com/paper/1803.06341