What does the exclusive lock on storage for OrientDB entail exactly?

Question

Having read the following statement from the official documentation of OrientDB:

In order to guarantee atomicity and consistency, OrientDB acquire an exclusive lock on the storage during transaction commit.

I am wondering if my understanding of the situation is correct. Here is how I assume this will work:

1. Thread 1 opens a transaction, and reads records #1:100 to #1:200, some from class A, and some from class B (something which cannot be determined without the transaction coming to a close).
2. Thread 1 massages the data, maybe even inserting a few records.
3. Thread 1 starts to commit the data. As the database does not have any way to know which parts of the data might be effected by the open transaction, it will blindly block the whole storage unit and verify the @version to enforce optimistic locking on all possibly affected records.
4. Thread 2 tries to read record #1:1 (or any other record from the whole database) and is blocked by the commit process, which is aligned, AFAIK with exclusive locking on the storage unit. This block occurs, if I'm not off, regardless of the cluster the original data resides on, since we have multi-master datasets.
5. Thread 1 ends the commit process and the database becomes consistent, effectively lifting the lock.
6. At this point, any thread can operate on the dataset, transactionally or otherwise, and will not be bound by the exclusive locking mechanism.

If this is the case, during the exchange highlighted in point 3 the data store, in its entirety is in an effective trance state and cannot be reached to, read from, or interacted with in any meaningful way.

I do so hope that I am missing my guess.

Disclaimer: I have not had the chance to dig into the underlying code from the rather rich OrientDB codebase. As such, this is, at its best, an educated guess and should not be taken as any sort of reference as to how OrientDB actually operates.

Possible Workarounds: Should worse come to worse and this happens to be the way OrientDB actually works, I would dearly welcome any workarounds to this conundrum. We are looking for meaningful ways that will still keep OrientDB as a viable option for an enterprise, scalable high-end application.

Answer 1

In current release of OrientDB, transactions lock the storage in exclusive mode. Fortunately OrientDB works in optimistic way and this is done "only" at commit() time. So no matter when the transaction is begun.

If this is a showstopper for your use case, you could consider to:

1. don't use transactions. In this case you'll go in parallel with no locks, but consider using indexes requires the usage of lock at index level. In case the index is a bottleneck, the most common workaround is to create X sub-classes with an index on each. OrientDB will use the index of sub-classes if needed and on CRUD operation only the specific index will be locked
2. wait for OrientDB 3.0 where this limitation will be removed with real parallel transaction execution