Welcome to the omid wiki! Omid stands for Optimistically transaction Management In Data stores. Here, we walk you through the architecture of CrSO in omid project and explain how you could use it.
CrSO adds lock-free transactional support on top of HBase. CrSO beneﬁts from a centralized scheme in which a single server, called status oracle, monitors the modiﬁed rows by transactions and use that to detect write-write conﬂicts. HBase clients in CrSO maintain a read-only copy of transaction commit times to reduce the load on the status oracle, making it scalable up to 50,000 transactions per second (TPS).
A transaction comprises a unit of work against a database, which must either entirely complete (i.e., commit) or have no effect (i.e., abort). In other words, partial executions of the transaction are not deﬁned. Without the support for transactions, the developers are burdened with ensuring atomic execution of a multi-row transaction despite failures as well as concurrent accesses to the database by other transactions. Data stores such as HBase, BigTable, PNUT, and Cassandra, usually lack this precious feature.
Snapshot isolation guarantees that all reads of a transaction are performed on a snapshot of the database that corresponds to a valid database state with no concurrent transaction. To implement snapshot isolation, the database maintains multiple versions of the data in some data servers, and transactions, run- ning by clients, observe different versions of the data depending on their start time. Implementations of snapshot isolation have the advantage that writes of a transaction do not block the reads of others. Two concurrent transactions still conﬂict if they write into the same data item, say a database row.
In the centralized implementation of snapshot isolation, a single server, i.e., the status oracle, receives the commit requests accompanied by the set of the identiﬁers (id) of modiﬁed rows, R. Since the status oracle has observed the modiﬁed rows by the previous commit requests, it has enough information to check if there is temporal overlap for each modiﬁed row. The timestamps are obtained from a timestamp oracle integrated into a status oracle and the uncommitted data of transactions are stored on the same data tables.
For each transaction, the status oracle server sends/receives the following main messages:
Since the timestamp oracle is integrated into the status oracle, the client obtains the start timestamp from the status oracle. The following list details the steps of transactions: