ACID-Compliant Transactions

There are many use cases when you need to update several documents consistently.

Imagine your documents represent a bank account balances and you need to transfer between two accounts. In this case you would subtract amount from one balance and add to other, however for all sorts of purposes you would like to see both operations done or none.
To make sure this happens both reads and writes have to enclosed with a transaction. Remember that Clusterpoint is a distributed database, so if you perform the same operations without enclosing transaction, Clusterpoint provides eventual consistency, which means that form some point in time you will see both updates, but there might be a point in time where some database reads can see database in inconsistent state. Enclosing all operations in a transaction ensures immediate consistency - as soon as commit command returns successfully, all subsequent reads see all updates in transaction.

In Clusterpoint users have a choice to execute data manipulation and retrieval statements in transaction or not. When executed outside of transaction updates are eventually consistent. While operations that are within transaction block are immediately consistent.

New transaction is started with BEGIN TRANSACTION statement (see REST example, PHP example):


A transaction is either committed or rolled back by the user or alternatively can be rolled back by the system due to race-condition with another transaction that system cannot recover form or not enough agents available to guarantee immediate consistency.

A transaction can be committed by the user with COMMIT statement:


or rolled back by the use with a ROLLBACK statement:


Performance implications

Of course, transactions come at cost because additional write of a transaction log is involved and transaction log state is synchronized, which in turn adds latency to commit operation. Thus if you do not require immediate consistency this performance penalty can be avoided.