ArangoDB v3.10 reached End of Life (EOL) and is no longer supported.

This documentation is outdated. Please see the most recent stable version.

HTTP interface for JavaScript Transactions

The HTTP API for JavaScript Transactions lets you run a transaction that leverages ArangoDB’s JavaScript API by submitting a single HTTP request

JavaScript Transactions are executed on the server. Transactions can be initiated by clients by sending the transaction description for execution to the server.

JavaScript Transactions in ArangoDB do not offer separate BEGIN, COMMIT and ROLLBACK operations. Instead, JavaScript Transactions are described by a JavaScript function, and the code inside the JavaScript function is then be executed transactionally.

At the end of the function, the transaction is automatically committed, and all changes done by the transaction are persisted. If an exception is thrown during transaction execution, all operations performed in the transaction are rolled back.

For a more detailed description of how transactions work in ArangoDB please refer to Transactions.

Execute a JavaScript Transaction

POST /_api/transaction

The transaction description must be passed in the body of the POST request.

If the transaction is fully executed and committed on the server, HTTP 200 will be returned. Additionally, the return value of the code defined in action will be returned in the result attribute.

For successfully committed transactions, the returned JSON object has the following properties:

  • error: boolean flag to indicate if an error occurred (false in this case)

  • code: the HTTP status code

  • result: the return value of the transaction

If the transaction specification is either missing or malformed, the server will respond with HTTP 400.

The body of the response will then contain a JSON object with additional error details. The object has the following attributes:

  • error: boolean flag to indicate that an error occurred (true in this case)

  • code: the HTTP status code

  • errorNum: the server error number

  • errorMessage: a descriptive error message

If a transaction fails to commit, either by an exception thrown in the action code, or by an internal error, the server will respond with an error. Any other errors will be returned with any of the return codes HTTP 400, HTTP 409, or HTTP 500.

Request Body application/json object

  • the actual transaction operations to be executed, in the form of stringified JavaScript code. The code will be executed on server side, with late binding. It is thus critical that the code specified in action properly sets up all the variables it needs. If the code specified in action ends with a return statement, the value returned will also be returned by the REST API in the result attribute if the transaction committed successfully.

  • Allow reading from undeclared collections.

  • collections must be a JSON object that can have one or all sub-attributes read, write or exclusive, each being an array of collection names or a single collection name as string. Collections that will be written to in the transaction must be declared with the write or exclusive attribute or it will fail, whereas non-declared collections from which is solely read will be added lazily. The optional sub-attribute allowImplicit can be set to false to let transactions fail in case of undeclared collections for reading. Collections for reading should be fully declared if possible, to avoid deadlocks.

  • an optional numeric value that can be used to set a timeout in seconds for waiting on collection locks. This option is only meaningful when using exclusive locks. If not specified, a default value of 900 seconds will be used. Setting lockTimeout to 0 will make ArangoDB not time out waiting for a lock.

  • Transaction size limit in bytes.

  • optional arguments passed to action.

  • an optional boolean flag that, if set, will force the transaction to write all data to disk before returning.

Responses

  • If the transaction is fully executed and committed on the server, HTTP 200 will be returned.

  • If the transaction specification is either missing or malformed, the server will respond with HTTP 400.

  • If the transaction specification contains an unknown collection, the server will respond with HTTP 404.

  • Exceptions thrown by users will make the server respond with a return code of HTTP 500

Examples

Executing a transaction on a single collection

curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_api/transaction
{
  "collections": {
    "write": "products"
  },
  "action": "function () { var db = require('@arangodb').db; db.products.save({});  return db.products.count(); }"
}
Show output

Executing a transaction using multiple collections

curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_api/transaction
{
  "collections": {
    "write": [
      "products",
      "materials"
    ]
  },
  "action": "function () {var db = require('@arangodb').db;db.products.save({});db.materials.save({});return 'worked!';}"
}
Show output

Aborting a transaction due to an internal error

curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_api/transaction
{
  "collections": {
    "write": "products"
  },
  "action": "function () {var db = require('@arangodb').db;db.products.save({ _key: 'abc'});db.products.save({ _key: 'abc'});}"
}
Show output

Aborting a transaction by explicitly throwing an exception

curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_api/transaction
{
  "collections": {
    "read": "products"
  },
  "action": "function () { throw 'doh!'; }"
}
Show output

Referring to a non-existing collection

curl -X POST --header 'accept: application/json' --data-binary @- --dump - http://localhost:8529/_api/transaction
{
  "collections": {
    "read": "products"
  },
  "action": "function () { return true; }"
}
Show output