31 March 2014
Category: announcement, orientdb
31 March 2014,

London, March 31st 2014

I’ve silently introduced a new feature in OrientDB (well, there was an issue, but I know somebody is not registered to GitHub notification). It’s about Transactions and Locking. Now every time you expressly lock records, all the locks are kept on the current transaction until the closing by commit() or rollback(). This means that it’s finally possible avoiding concurrent updates.

The real question is: “Is it better to be Optimistic or Pessimistic with transactions?”

  • Optimistic (like CAS) avoiding locking and resolve conflicts by re-executing the transaction with a retry policy or
  • Pessimistic by locking the records, apply changes and then unlock them


The response is up to you, or better, to your use case. In general the Optimistic approach is preferable on modern multi-core architecture, but on massive updates against few records locking could take the best performance.

Look at this micro-benchmark.

This feature along with the new server side SQL batch, give us a lot of power. Let’s see how to create an edge with Pessimistic approach (locking) and with Optimistic approach (CAS).

Pessimistic approach

let $client = create vertex Client set name = ‘Luca’
let $city = select from City where name = ‘London’ lock record
let $e = create edge Lives from $client to $city


Optimistic approach

let $client = create vertex Client set name = ‘Luca’
let $city = select from City where name = ‘London’
let $e = create edge Lives from $client to $city retry 100

Now it’s up to you choosing the best approach for your use case.
Luca Garulli
CEO at Orient Technologies
the Company behind OrientDB




Leave a Reply