Article Preview
TopIntroduction
The CAP theorem (Brewer, 2000; Gilbert & Lynch, 2002) proves that having both availability and partition tolerance within disparate databases that implement strong consistency (Herlihy & Wing, 1990) is not possible. Strong consistency is the strongest type of consistency offered by traditional distributed database management systems (DDBMSs), that manage databases spread across multiple nodes.
The rise of cloud-oriented, distributed infrastructures has led to a wide adoption of databases whose state management foregoes strong data consistency in favour of availability and partition tolerance, to provide the performance, scalability and high-availability properties sought by enterprise-grade online applications. Popular DDBMSs, such as MongoDB (DoubleClick, ShopWiki, & GiltGroupe, 2007), offer eventual consistency (Vogels, 2009), a weak consistency model which guarantees that given no new WRITE operations, all disparate nodes of the database eventually converge to the same state.
Eventual consistency is relatively easy to implement and performs well (in terms of transaction throughput) even when the underlying databases are geo-replicated. This is in contrast to the use of consensus algorithms such as Paxos (Lamport, 1998), that aim to achieve availability and strong consistency on geo-replicated databases, but tend to suffer from performance overheads in a distributed environment (Guo et al., 2017; Rao, Shekita, & Tata, 2011). However, eventual consistency shifts data safety and consistency responsibilities from DDBMS components to the application layer, giving rise to a new set of problems (Elbushra & Lindström, 2014).
Causal consistency (Ahamad, Neiger, Burns, Kohli, & Hutto, 1995) is weaker than strong consistency, but stronger than eventual consistency, and has been proven to be the strongest type of consistency that can be achieved in a fault-tolerant, distributed system (Mahajan, Alvisi, & Dahlin, 2011). Informally, causal consistency implies that readers cannot find a version of a data element before all the operations that led to that version are visible (Bailis, Ghodsi, Hellerstein, & Stoica, 2013).
This paper gives a brief grounding of the topic, and a short overview and evaluation of similar works found in the literature. The authors briefly discuss their previous work, Thespis (Camilleri et al., 2017), a middleware approach that offers causal consistency encapsulated in a layer of REST services, such that its integration within enterprise applications is as straightforward as possible.
Subsequently, using a real-world scenario, it is illustrated that whilst causal consistency can be guaranteed with a simple API (such as that offered by Thespis and other works in the literature), an enterprise application is still be expected to deal with the complexities of Time-To-Check-Time-To-Use (TOCTOU) race conditions. Such race conditions can be easily avoided when interfacing with a transactional DBMS (e.g. relational DBMS), but are non-trivial to deal with at application level and can cause non-deterministic runtime behaviour.
The system design of ThespisTRX is then presented, which extends the Thespis framework with causally-consistent read-only transactions (Lloyd et al., 2013). At the same time, ThespisTRX keeps a similarly simple and intuitive API, and therefore does not diverge from the original objectives of the Thespis framework.
The correctness of the design is also assessed, to demonstrate how read-only transactions isolate the enterprise application from the complexities of TOCTOU race conditions. Finally, the implementation of ThespisTRX is evaluated with empirical experiments using YCSB (Cooper et al., 2010), that show that supporting read-only transactions is possible to with minimal performance overheads.