Transactions - Neo4j in Action - page 170

likely have a negative impact on the performance of your application. Besides the over-
headaddedbycreatinganewtransactionforeachrequest,themultiplenetworkcallsalone
could prove catastrophic for performance. In order to help address some of these issues,
the following options for handling transaction scenarios in a server context should be con-
sidered:
• Using the REST Cypher endpoint —Provides the ability to execute a single
Cypherstatement,whichmayresultinmultiplenodesand/orrelationshipsneeding
tobeupdated.Allaffected nodes/relationships willbeupdatedaspartofthesingle
HTTP request.
• Using the REST transactional endpoint —Provides the ability to execute a series
of Cypher statements within the scope of a transaction, but unlike the Cypher end-
point, over multiple HTTP requests.
• Using the REST batch endpoint —Provides the ability to define a job—a set of
low-level REST API calls to be executed as a single transaction when sent to the
batch REST endpoint.
• Using server plugins or unmanaged extensions —Provides the ability to define
Java code that can be run within the Neo4j server itself as a result of a REST call,
providing full programmatic control (including transaction handling).
7.5. Summary
Transactions can be a complicated topic, but hopefully you now understand how Neo4j al-
lows you to take full advantage of ACID-based transactions to manage concurrent access
to graph resources.
We've covered how transactions work in detail: the default transaction behavior is satis-
factoryformostcommoncases,butwe'veexaminedtheimplicationsoftransactionstrying
to access the same graph resources at the same time and how higher isolation levels can be
achieved by using read and write locks explicitly.
Enterprise applications are often built on top of a framework such as Spring, and we've
covered how Neo4j transactions can be integrated with Spring's transaction management
system, taking advantage of Spring's declarative approach.