Getting Started

Omid provides ACID transactions with Snapshot Isolation guarantees for HBase data stores. It is composed of 4 main components:

1. Transactional Clients. Allow client applications to demarcate transaction boundaries through the so-called Transaction Manager and to perform transactional read/write operations on data through Transactional Tables.
2. Transaction Status Oracle (TSO). Its the central element of the Omid architecture on the server-side. When requested by the client, the TSO assigns start and commit timestamps that demarcate each transaction and resolves conflicts between concurrent transactions.
3. Commit Table (CT). Stores a transient mapping start timestamp -> commit timestamp in the data store (HBase)
4. Shadow cells (SCs). These special metadata cells are written alongside data cells in the data store to allow client to resolve reads without consulting the Commit Table. They contain the transactional boundaries of the last transaction in writing to the data cell.

For a detailed picture of the Omid architecture, please refer to the Omid Components section in the technical documentation.

Transactional Contexts and Operations with Omid

As stated above, applications requiring transactions will use the interfaces provided by the Omid Transactional Client.

When starting a transaction, the Omid Transactional Client requests a start timestamp from the TSO. This timestamp marks the beginning of a transactional context, that is, a transaction. From that point on, the client application can perform transactional read and write operations on the data source:

• Read Ops. The client first checks if the cell has a Shadow Cell (SC). If the cell has a SC and the commit timestamp is lower than the start timestamp of the reading transaction, then the client can "see" the cell, that is, it's in its snapshot. If there is no SC, the Commit Table (CT) is consulted to find the commit timestamp of the cell. If the commit timestamp does not exist in the CT, then the cell is assumed to below to an aborted transaction.
• Write Ops. The client directly writes optimistically in the data source any data cells it wishes adding the start timestamp as the version of each data cell. The metadata of each cell written is added also to the so-called write-set of the transaction.

To commit a transaction, the client sends the write-set of the transaction to the TSO, which will check for conflicts in the transaction write-set with other transactions executing concurrently:

• Conflicts -> the transaction is aborted and the roll-back outcome is returned to the client.
• No conflicts -> the TSO assigns a commit timestamp to the transaction, writes the mapping start timestamp -> commit timestamp to the CT and returns commit as an outcome for the transaction to the client.

On receiving the outcome for the transaction, the client:

• For roll-backs -> it clears the written cells.
• For commits -> it updates the shadow cells for the cells in the write-set and clears the entry for that transaction in the CT.

This is just a quick introduction to Omid. More details can be found in the About Omid and Technical Documentation sections of the wiki.

Next steps:

• Installation
• Basic Examples