ThespisTRX: Causally-Consistent Read Transactions

ThespisTRX: Causally-Consistent Read Transactions

Carl Camilleri (Department of Computer Information Systems, University of Malta, Malta), Joseph G. Vella (Department of Computer Information Systems, University of Malta, Malta) and Vitezslav Nezval (Department of Computer Information Systems, University of Malta, Malta)
DOI: 10.4018/IJITWE.2020010101


Data consistency defines how usable a data set is. Causal consistency is the strongest type of consistency that can be achieved when data is stored in multiple locations, and fault tolerance is desired. Thespis is a middleware that innovatively leverages the Actor model to implement causal consistency over a DBMS, whilst abstracting complexities for application developers behind a REST interface. Following the evaluation of correctness, performance and scalability of Thespis, it is illustrated how a business application can be guaranteed causal consistency, but still encounter Time-To-Check-Time-To-Use (TOCTOU) race conditions. The design and implementation of ThespisTRX is given, which builds upon, and extends, the Thespis middleware to offer read-only transaction capabilities, allowing clients to read a causally-consistent version of multiple data entities. A correctness analysis illustrates how ThespisTRX avoids TOCTOU race conditions, and empirical performance tests show that this can be achieved with minimal overheads.
Article Preview


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.

Complete Article List

Search this Journal:
Open Access Articles: Forthcoming
Volume 16: 4 Issues (2021): Forthcoming, Available for Pre-Order
Volume 15: 4 Issues (2020): 3 Released, 1 Forthcoming
Volume 14: 4 Issues (2019)
Volume 13: 4 Issues (2018)
Volume 12: 4 Issues (2017)
Volume 11: 4 Issues (2016)
Volume 10: 4 Issues (2015)
Volume 9: 4 Issues (2014)
Volume 8: 4 Issues (2013)
Volume 7: 4 Issues (2012)
Volume 6: 4 Issues (2011)
Volume 5: 4 Issues (2010)
Volume 4: 4 Issues (2009)
Volume 3: 4 Issues (2008)
Volume 2: 4 Issues (2007)
Volume 1: 4 Issues (2006)
View Complete Journal Contents Listing