Phoenix Transactions

Phoenix Transactions

Above and beyond the row-level transactional semantics of HBase, Phoenix adds cross row and cross table transaction support with full ACID semantics by integrating with Tephra, now an Apache incubator project. Tephra provides snapshot isolation of concurrent transactions by implementing multi-versioned concurrency control.

Setting up a system to use transactions in Phoenix requires two steps:

1. Add the following config to your client side hbase-site.xml file to enable transactions:
   <property>
2.   <name>phoenix.transactions.enabled</name>
3.   <value>true</value>
4.   </property>
5. 
   
6.  2   Add the following config to your server side hbase-site.xml file to configure the transaction manager: The “Transaction Server Configuration” section of Tephra describes the available configuration options.
   <property>
7.       <name>data.tx.snapshot.dir</name>
8.      <value>/tmp/tephra/snapshots</value>
9.    </property>
   
10.   Also set the transaction timeout (time after which open transactions become invalid) to a reasonable value.
    <property>
11.       <name>data.tx.timeout</name>
12.       <value>60</value> 
13.     </property>
14. 
    
15. 3   Set $HBASE_HOME and start the transaction manager:
    ./bin/tephra
    

The transaction manager would typically be configured to run on one or more of the master nodes in your HBase cluster

Once this setup is done, transactions may then be enabled on a table by table basis by using the TRANSACTIONAL=true property when you create your table:

CREATE TABLE my_table (k BIGINT PRIMARY KEY, v VARCHAR) TRANSACTIONAL=true;

An existing table may also be altered to be transactional, but be careful because you cannot switch a transactional table back to being non transactional:

ALTER TABLE my_other_table SET TRANSACTIONAL=true;

Limitations

1. Starting a transaction on a connection with an SCN set is not allowed.
2. Setting the maximum number of versions property while creating a transactional table limits the number of snapshots available for concurrent transactions.
3. When a transaction times out or if it cannot be rolled back by the client, it is added to an invalid list. This list can potentially grow if there are a lot of failed or timed out transactions. For now, an adminstrator can manually clear transactions from this list after a major compaction has occurred. TEPHRA-35 describes ongoing work to automatically remove transactions from the invalid list once all data associated with the transaction has been removed.
4. If adding an index asynchronously to an existing transactional table, make sure to run a major compaction before issuing the CREATE INDEX ASYNC command as otherwise invalid and/or uncommitted transactions may appear in your index PHOENIX-2154.