OrientDB 的存储独占锁到底意味着什么？
What does the exclusive lock on storage for OrientDB entail exactly?
阅读了OrientDB官方文档中的如下声明：
In order to guarantee atomicity and consistency, OrientDB acquire an
exclusive lock on the storage during transaction commit.
我想知道我对情况的理解是否正确。这是我认为这将起作用的方式：
- 线程 1 打开一个事务，并读取记录
#1:100 到 #1:200，一些来自 class A，并且一些来自 class B（如果交易未结束则无法确定）。
- 线程 1 处理数据，甚至可能插入几条记录。
- 线程 1 开始提交数据。由于数据库无法知道哪些部分的数据可能会受到开放事务的影响，它会盲目地阻塞整个存储单元并验证
@version以对所有可能受影响的记录强制执行乐观锁定。
- 线程 2 尝试 读取 记录
#1:1（或整个数据库中的任何其他记录）并被阻止提交过程，这是对齐的，AFAIK 存储单元上的独占锁定。这个块发生，如果我没有关闭，不管原始数据所在的集群，因为我们有多主数据集。
- 线程 1 结束提交过程，数据库变得一致，有效解除锁定。
- 至此，任何线程都可以对数据集进行操作，无论是事务性的还是其他的，都不会被独占锁定机制所束缚。
如果是这种情况，在点 3 中突出显示的交换期间，数据存储整体处于有效的恍惚状态，无法访问、读取、或以任何有意义的方式与之互动。
真希望我没猜错。
免责声明：我还没有机会从相当丰富的 OrientDB 代码库中挖掘底层代码。因此，这充其量只是一种有根据的猜测，不应被视为关于 OrientDB 实际运作方式的任何参考。
可能的解决方法：
如果情况变得更糟，而这恰好是 OrientDB 实际工作的方式，我将非常欢迎任何解决这个难题的方法。我们正在寻找有意义的方法，使 OrientDB 仍然是企业、可扩展的高端应用程序的可行选择。
在当前版本的 OrientDB 中，事务以独占模式锁定存储。幸运的是，OrientDB 以乐观的方式工作，这是在 commit() 时完成的 "only"。所以无论什么时候开始交易。
如果这是您用例的亮点，您可以考虑：
- 不使用交易。在这种情况下，您将在没有锁的情况下并行进行，但考虑使用索引需要在索引级别使用锁。如果索引是瓶颈，最常见的解决方法是创建 X sub-类 并在每个索引上创建一个索引。如果需要，OrientDB 将使用 sub-类 的索引，并且在 CRUD 操作中只会锁定特定索引
- 等待 OrientDB 3.0 真正的并行事务执行将消除此限制
阅读了OrientDB官方文档中的如下声明：
In order to guarantee atomicity and consistency, OrientDB acquire an exclusive lock on the storage during transaction commit.
我想知道我对情况的理解是否正确。这是我认为这将起作用的方式：
- 线程 1 打开一个事务，并读取记录
#1:100到#1:200，一些来自 classA，并且一些来自 classB（如果交易未结束则无法确定）。 - 线程 1 处理数据，甚至可能插入几条记录。
- 线程 1 开始提交数据。由于数据库无法知道哪些部分的数据可能会受到开放事务的影响，它会盲目地阻塞整个存储单元并验证
@version以对所有可能受影响的记录强制执行乐观锁定。 - 线程 2 尝试 读取 记录
#1:1（或整个数据库中的任何其他记录）并被阻止提交过程，这是对齐的，AFAIK 存储单元上的独占锁定。这个块发生，如果我没有关闭，不管原始数据所在的集群，因为我们有多主数据集。 - 线程 1 结束提交过程，数据库变得一致，有效解除锁定。
- 至此，任何线程都可以对数据集进行操作，无论是事务性的还是其他的，都不会被独占锁定机制所束缚。
如果是这种情况，在点 3 中突出显示的交换期间，数据存储整体处于有效的恍惚状态，无法访问、读取、或以任何有意义的方式与之互动。
真希望我没猜错。
免责声明：我还没有机会从相当丰富的 OrientDB 代码库中挖掘底层代码。因此，这充其量只是一种有根据的猜测，不应被视为关于 OrientDB 实际运作方式的任何参考。
可能的解决方法： 如果情况变得更糟，而这恰好是 OrientDB 实际工作的方式，我将非常欢迎任何解决这个难题的方法。我们正在寻找有意义的方法，使 OrientDB 仍然是企业、可扩展的高端应用程序的可行选择。
在当前版本的 OrientDB 中，事务以独占模式锁定存储。幸运的是，OrientDB 以乐观的方式工作，这是在 commit() 时完成的 "only"。所以无论什么时候开始交易。
如果这是您用例的亮点，您可以考虑：
- 不使用交易。在这种情况下，您将在没有锁的情况下并行进行，但考虑使用索引需要在索引级别使用锁。如果索引是瓶颈，最常见的解决方法是创建 X sub-类 并在每个索引上创建一个索引。如果需要，OrientDB 将使用 sub-类 的索引，并且在 CRUD 操作中只会锁定特定索引
- 等待 OrientDB 3.0 真正的并行事务执行将消除此限制