Concurrency OrientDB的独家存储锁定究竟意味着什么？

阅读了OrientDB官方文件中的以下声明：

为了保证原子性和一致性，OrientDB获得 事务提交期间对存储的独占锁定

我想知道我对形势的理解是否正确。以下是我认为这会起作用的方式：

线程1打开一个事务，并将记录从

#1:100

读取到

#1:200

，其中一些来自类

a

，另一些来自类

B

（在事务结束之前无法确定的内容）

线程1处理数据，甚至可能插入一些记录

线程1开始提交数据。由于数据库无法知道打开的事务可能会影响数据的哪些部分，它将盲目地阻止整个存储单元，并验证

@version

，以对所有可能受影响的记录实施乐观锁定

线程2尝试读取记录

#1:1

（或整个数据库中的任何其他记录），并被提交进程阻止，该进程与存储单元上的独占锁定对齐。如果我没有关闭，不管原始数据驻留在哪个集群上，都会发生此块，因为我们有多个主数据集

线程1结束提交过程，数据库变得一致，有效地解除了锁定

此时，任何线程都可以对数据集进行事务性或其他操作，并且不会受到独占锁定机制的约束

在这种情况下，在第3点突出显示的交换期间，数据存储整体处于有效的恍惚状态，无法以任何有意义的方式访问、读取或交互

我希望我没有猜到

免责声明：我没有机会从相当丰富的OrientDB代码库中挖掘底层代码。因此，这充其量只是一个有根据的猜测，不应作为OrientDB实际运行方式的任何参考

可能的解决办法：

---

如果情况变得更糟，而这恰好是OrientDB实际工作的方式，我非常欢迎任何解决这一难题的方法。我们正在寻找有意义的方法，使OrientDB仍然是企业、可扩展的高端应用程序的可行选项。

在OrientDB的当前版本中，事务以独占模式锁定存储。幸运的是，OrientDB的工作方式是乐观的，这“只”在提交（）时完成。因此，无论交易何时开始

如果这是你的用例的展示器，你可以考虑：

不要使用事务。在这种情况下，您将并行执行无锁，但考虑使用索引需要使用索引级别的锁。如果索引是一个瓶颈，最常见的解决方法是创建X个子类，每个子类上都有一个索引。如果需要，OrientDB将使用子类的索引，在CRUD操作中，仅锁定特定索引

等待OrientDB 3.0，该限制将通过真正的并行事务执行被删除

---

谢谢你的评论。关于OrientDB 3.0的生产就绪版本何时能进入下载市场，我们有什么见解吗？OrientDB 3.0将于2015年7月至8月正式上市。