maximum writer). This would allow us to code the standard rules of Optimistic Concurrency Control, and so prevent concurrent conflicting accesses while allowing concurrent readers.
5.16
Correctness for Serializable transactions
The “Atomicity”, “Durability” and “Consistency” results from Section 5.14 di- rectly apply to Algorithm 7, which executes all the steps of the usual CG protocol, but also does some extra version creations. Therefore, all we need to show here is that the “Isolation” provided with this algorithm is Serializable.
In order to evaluate the isolation characteristics of the Algorithm 7 we will construct the equivalent serial execution, based on placing the transactions into the serial execution according to an appropriate total order, one that relates all the transactions. For a system that uses Algorithm 7 along with the usual Cherry Garcia commit processing, the total order that will serialise transactions is the order defined by the commit timestamps. That is, we define T < T0 by T.commit time < T0.commit time.
As an aid to the argument, we will use the ideas of distributed transaction management, whereby one can consider a global distributed execution in terms of the sub-transactions at each site, and we apply that in a model where each data record is treated as a separate site. That is, we will consider the activity of the various transactions on a single record at a time. We here quote Theorem 18.1 in Chapter 18 of Weikum and Vossen [139] which states the following fundamental result, that global serializability follows from local (conflict) serializability when there is a common total order on the transactions that can serialise each site separately:
Theorem 5.16.1 Let s be a global history with local histories s1, . . . , sn
involving a set T of transactions such that each si, 1 ≤ i ≤ n, is conflict
serializable. The following holds:
s is globally conflict serializable iff there exists a total order “<” on T that is consistent with the local serialization order of the transactions, i.e.,
(∀t, t0 ∈ T, t 6= t0) =⇒
(∀si, 1 ≤ i ≤ n, t, t0 ∈ trans(si))(∃s0i, s0iserial, si ≈cs0i) t <s0i t0
Now we prove serializability by applying the above theorem, together with the following lemma, that indicates that for any given record r, the local activity of the system on r is equivalent to executing those same activities (excluding those from aborted transactions) in the serial order defined by commit timestamps.
Lemma 5.16.2 When executing Algorithm 7 along with the other protocols ac- cording to Cherry Garcia, the return value when transaction T reads record r is the value of the version created by the transaction U such that U has the greatest commit timestamp among all transactions that wrote r and committed before T .
Proof We build on the arguments from Section 5.14, with the added information that Algorithm 7 ensures that a version is created for every record accessed in a transaction, and that for transactions that do not modify r, the version they produce has the same value as the previous version of r. Lemma 5.14.1 tells us that the return value for T will be that of the version produced by the transaction with highest timestamp that produced a version of r and committed before T started; because each transaction either is a writer of r, or else it keeps the same value in the version it produces as was there before, this is the same as the value from the highest timestamp among writers of r that commit before T starts. Now we appeal to Lemma 5.14.2, to see that no transaction that wrote r is concurrent with T ; that is, the highest timestamp among writers of r that commit before T starts, is exactly the highest timestamp among writers of r that commit before T commits. This is exactly what the lemma here requires.
5.17
Chapter Summary
Database technology has evolved significantly over the years, however, the basic principles, particularly those related to correctness and transaction behaviour, remain the same. We use the principles developed over many years of research and development to define Cherry Garcia, a protocol that enables scalable transactions across heterogeneous data stores. We began by describing the challenges faced in the modern enterprise related to application development with the rapid and
5.17. CHAPTER SUMMARY 117
prolific growth of web-services and other endpoints. Then, the intuition and basis of our approach was described using the analogy of a deconstructed write-ahead log (WAL). Later, we provided a detailed description of the commitment protocol and associated state management. This was followed by a description of the Cherry Garcia client library, whose implementation in Java we will describe in further detail in Chapter 6. Chapter 8 will be dedicated to the evaluation of Cherry Garcia to understand its characteristics under various environmental conditions. This is done using both micro-benchmarks as well as the YCSB+T benchmark.
Chapter 6
Implementation
In this chapter, we begin by describing the implementation of Cherry Garcia, the Java library, and its various components. Next, we describe the Datastore abstrac- tions for Windows Azure Storage (WAS), Google Cloud Storage (GCS) and Tora, a high-performance key-value store with a REST+T (extended HTTP) interface built using a WiredTiger [140] storage engine. Later, we provide an overview of the implementation of Tora and the extension to the Apache HttpClient library to support REST+T methods.
6.1
Implementation Overview
The Cherry Garcia library is implemented in Java using the standard Java classes available with JDK 1.6 and the Apache HTTP client1 library. The UML diagram
of the Cherry Garcia library in Figure 6.1 describes the relationship between the Transaction, Datastore, Record and other associated classes.
In Cherry Garcia, timestamps are obtained using an pluggable implementation of the TrueTime API. The default implementation of this references the clock on the local host. This makes it possible to switch to an alternate time system in the future by changing just runtime settings.
A Transaction Status Record (TSR) is needed by every update transaction to capture transaction state. In order to prevent this from becoming a serialisation bottleneck, we can distribute the load exerted upon the Coordinating Data Store
1https://hc.apache.org/
start() read() write() delete() abort() commit() TxID Transaction open() close() start() read() write() prev() delete() abort() prepare() commit() recover() Name Datastore 1 * get() put() delete() RecordCache get() put() delete() HashMap Name Credentials AzureDatastore Name Credentials GoogleDatastore Name Credentials ToraDatastore Value Record TxID ETag start_time commit_time lease_time RecordHeader * 1 1 1
Figure 6.1: UML class diagram of the Cherry Garcia library
(CDS) to process TSR requests across all the participating data stores. Since a given transaction needs a particular data store to maintain its TSR. Different transactions can store their TSRs in different data stores so that a single data does not become a bottleneck. The transaction identifier used in this scheme is a Universal Resource Identifier (URI) specifying the location of the TSR so that it can be accessed by any client reading the record.
The Datastore implementation (Google, Azure, and Tora) performs version management of data records based on the characteristics of each data store. Two versions of each record, the currently committed/prepared version and the pre- viously committed version, are needed. If the data store does not natively offer version support (like Tora does), the Datastore class encodes both versions within a single BLOB. Garbage Collection is not a concern here since older versions are overwritten with each new version created.