Component based transaction locks since OrientDB 2.2.5

In versions of OrientDB prior of 2.2.5, all transactions are performed under global storage lock. What did it mean? Transactions were completely serializable, but for the cost of multi-core scalability.

Since OrientDB 2.2.5 we use component locking approach. So for example, if your transaction includes updates or insertions of documents which belong to several classes following steps will be done:

1. If you insert a record, one of the clusters which are used to store documents for given class will be chosen and locked. If you update/delete record cluster to which record belongs will be locked.
2. All indexes are affected by data which you change will be locked.
3. Transaction commit will be performed.
4. All components will be unlocked.

To increase OrientDB scalability, we spread all records of each class among several clusters. By default amount of clusters which are used to store documents of single class equals to amount of cores on your system.

If you wish you may increase transactions scalability by execution of command: ALTER DATABASE MINIMUMCLUSTERS <amount of clusters>

Of course, we will not stop on component locking approach. We plan eventually to migrate to ARIES based transactions which are operating on locks with a record and key granularity.