31 March 2014
31 March 2014,
 0

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

begin
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
commit

 

Optimistic approach

begin
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
commit

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

http://about.me/luca.garulli

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>