Neo4j Database – Part 08 – Transactions

In the last blog I showed some sample queries. In this blog I will explain how transactions are used.


NoSQL databases typically follow the BASE principal and RDBMS’s follow the ACID principal. Neo4j is actually fully ACID compliant. What is quite strange about the Cypher language is that it does not have any commands to start and complete a transaction. Transactions are managed through the REST API web service when executed from a client application.


I said there were no transaction commands in Neo4j; there is one. USING PERIODIC COMMIT is used with the LOAD CSV command to reduce the memory consumption for the load process. This prevents out of memory conditions when importing a large amount of data.

HTTP Transaction Endpoint

The HTTP endpoint allows one or more Cypher statements to be executed within a single transaction. You can then either commit the transaction or rollback the transaction. You can even keep the transaction open across multiple requests. If a transaction gets orphaned for any reason, there is a server setting to control the timeout period for this. The default is 60 seconds.

Begin a Transaction

A transaction is started with a POST to URL <server>/db/data/transaction. The response message will include a transaction ID which is needed in order to commit or rollback the transaction.

Commit a Transaction

A transaction is committed with a POST to URL <server>/db/data/transaction/<ID>/commit

Adding Commands Over Multiple Requests

If a transaction is open we can add additional commands with a POST to URL <server>/db/data/transaction/<ID>

Rolling Back a Transaction

To rollback a transaction send a DELETE request URL <server>/db/data/transaction/<ID>

Begin and Commit is a Single Request

The endpoint allows us to begin a transaction, execute some commands and commit the transaction in a single request. Just send a POST to URL <server>/db/data/transaction/commit.

Transactions in Client APIs

When using client APIs for example; .NET, Javascript, Python, etc; they will have their own way of expressing the transactions which ultimately end up with the calls discussed above.

In the next blog I will discuss scalability.