(originally posted on SO <http://stackoverflow.com/questions/30044313>)
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: - *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). - *Thread 1* massages the data, maybe even inserting a few records. - *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. - *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. - *Thread 1* ends the commit process and the database becomes consistent, effectively lifting the lock. - 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. -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
