Dspace双写RDBMS和SOLR vs并发

Question

我想知道dspace如何管理数据库和solr中的索引，同时支持并发性。换句话说，如果两个个体试图同时在同一项上写入(例如更改元数据)，那么dspace如何确保索引不会与数据库进行去同步。

如果USER1与用户2以相同的元数据值并发写入，而对用户1的数据库的写入首先发生，然后发生对数据库和USER2索引的写入，然后发生对USER1索引的写入，则可能发生这种情况。

换句话说，USER1“写”将在索引中，而User2写将在数据库=不一致！

我想知道如何在dspace中避免这种情况，这是一个典型的双写问题。

使用dspace的事件系统，我不知道如何才能避免这种情况。

有人知道吗？

​

​

Answer 1

在Solr中，DSpace不只是索引单个元数据更改(发生时)。它实际上在Solr中重新索引整个项。

这意味着，虽然并发性是数据库层中的一个问题(并且写入/更新在数据库中是同步的)，但它不是Solr索引过程中的问题。

下面是在您的示例中将会/应该发生的事情。

1. 用户1和用户2同时编辑同一项的标题。
2. 编辑将在数据库级别同步，以便首先进行第一个编辑。让我们假设用户1的编辑首先发生，然后用户2的编辑。
3. 用户1的编辑将触发Solr中的重新索引。用户2的编辑也是如此。这意味着同一项将被重新编制两次索引(每次编辑一次)。这些重新索引不绑定到特定的更新(因此第一个重新索引不只是索引标题)，而只是告诉Solr该项已经更新，它需要重新索引。
4. 在第一次重新索引时，用户1的编辑已经完成，因此该项将被编入该标题的索引。
5. 到第二次重新索引时，用户2的编辑将已经完成(因为重新索引比将编辑保存到DB层需要更长的时间)，因此该项将(重新)与更新的标题进行索引。

因此，这里的简单答案是，DSpace不会重新索引单个修改(如果不与DB编辑同步，这可能会导致无序)。相反，它跟踪已更新的对象并触发整个对象的元数据的重新索引。虽然这看起来像是“过火”，但Solr中单个对象的重新索引并不完全是进程密集型的，它确保对象的当前/最新元数据在Solr中进行索引(在同时写入的情况下)。

更新:根据请求(在下面的注释中)，下面是DSpace如何更详细地执行重新索引(在Solr中)。

1. DSpace有一个已定义的事件系统。下面是本节中dspace.cfg中的配置：X/dspace/config/dspace.cfg#L 732
2. 默认情况下，在DSpace 5中，IndexEventConsumer为Solr执行索引。默认情况下，它是在这里定义的：X/dspace/config/dspace.cfg#L 732
3. 在DSpace 5中，每当有人更改项的元数据(或任何有关项的内容)时，都会调用Item.update()方法将更改保存回数据库层。
4. 保存所有更改(使用DatabaseManager.update())后，Item.update()方法将生成一个事件系统中的新修改事件。
5. 新的修改事件被追加到当前上下文中事件的LinkedList
6. 当上下文已提交 (在保存更改时发生)时，它首先调用DB连接上的commit (结束事务)。然后，它将事件列表发送给Dispatcher (默认情况下，BasicDispatcher在dspace.cfg中配置)，然后在Solr中触发索引(通过配置的IndexEventConsumer)。
7. IndexEventConsumer将update对象列表(在本例中是一个项)传递给IndexingService (默认情况下是SolrServiceImpl)。
8. 最后，SolrServiceImpl.indexContent()从数据库中读取最新的元数据值，并在Solr中对它们进行索引。

上面的逻辑仍然有点简单(因为它太复杂了，无法遍历代码的每一步)。但是，这里的基本要点是，每个Item.update()调用都被视为一个数据库事务。它还触发一个修改事件的添加，该事件存储在用户的会话(Context对象)中。一旦提交了DB事务，修改事件就由重新索引整个项的IndexEventConsumer处理。

因此，在同时编辑的情况下，将生成两个修改事件(每个编辑一个)。但是，直到提交了最后一个数据库编辑之后，才会触发最后一个修改事件。因此，Solr索引应该始终与数据库中的最新信息同步。