How can I do an atomic operation to a document field in ArangoDB?

Question

I would like to know which is best way to do this with ArangoDB, I started using transactions, or updating it records using revision check, but it's not very good with many concurrent updates.

With the new release 2.1 I see that that I can register functions in the server to execute every X amount of time, as I'm keeping raw data for a long period of time, I can count it async using one server task but It gives more latency to the counter.

Is there any other way to do it?

Thanks,

Diego Guraieb

Answer 1

At the moment there would be at least three ways to increase a counter:

1. let the client fetch the fetch counter value, increase it and send the updated document back to the server. on update, check with the document's etag / revision id whether there was a concurrent update and repeat if yes
2. create a server-side transaction that performs the update. an example (not using a counter but a list modification can be found here: https://groups.google.com/forum/#!topic/arangodb/2t9RV4eYUi4 )
3. save each counter modification operation (eg {"op":"inc","value":1}) separately, and calculate the current counter periodically using a server-side task. This alternative 3 can also be implemented in an incremental fashion if desired.

Alternative 1 will require at least 2 HTTP calls (fetch + update), and you will need error handling for the case of a concurrent update. So it's not very useful.

Alternative 2 will be the easiest-to-use from the client perspective I think. It allows exposing the "increase counter" operation via the REST API, and the fetch-and-update can be implemented in an atomic transaction.

Alternative 3 will work, too, if you can afford your counters to be slightly outdated. When implemented, it should be implemented incrementally, eg by keeping a total for the counter and adding only the new values on each update task execution. Otherwise your "counter operations" collection will grow infinitely and updates will become slower and slower. Alternative #3 also has the advantage that you can keep a (small) log of recent operations, eg for auditing.