database - Dspace双重写入RDBMS和SOLR与并发

Question

我想知道在支持并发的同时，dSu空间如何管理数据库和SOLR中的索引。换言之，如果两个人试图同时在同一项上写入（例如更改元数据），dspace如何确保索引不会与数据库解除同步。
如果用户1与用户2在同一元数据值上同时写入，并且首先写入用户1的数据库，然后写入数据库和用户2的索引，然后写入用户1的索引，则会发生这种情况。
换句话说，user1“write”将在索引中，而user2 write将在数据库中=不一致！！！
我想知道在dspace中如何避免这种情况，dspace是一个典型的双写问题。
有了dspace的事件系统，我不知道如何才能避免这种情况。
有人知道吗？

Answer 1

在solr中，dspace不只是索引单个元数据更改（当它发生时）。它实际上在solr中重新索引了整个项目。
这意味着，虽然并发是数据库层中的一个问题（并且写入/更新在数据库中是同步的），但它不是SOLR索引过程中的一个。
以下是在你的例子中会/应该发生的事情。
用户1和用户2同时编辑同一项的标题。
编辑将在数据库级别同步，以便首先进行第一次编辑。假设首先是用户1的编辑，然后是用户2的编辑。
用户1的编辑将触发solr中的重新索引。用户2的编辑也将如此。这意味着同一个项目将重新编制两次索引（一次为
每次编辑）。这些重新索引与特定更新无关（因此第一个Reindex不仅索引标题），而且只告诉SURR该项被更新并且需要重新索引。
在第一次重新索引时，将对用户1进行编辑，因此将使用该标题索引该项。
到第二次重新编制索引时，用户2的编辑已经完成（因为重新编制索引比将编辑保存到db层所需的时间更长），因此该项将使用更新的标题（重新）编制索引。
所以，这里的简单答案是，dspace不会重新索引单个修改（如果不与db编辑同步，可能会导致无序）。相反，它跟踪哪些对象已经更新，并触发整个对象元数据的重新索引。虽然这看起来像是“过度杀戮”，但solr中单个对象的重新索引并不是所有过程密集型的，它确保对象的当前/最新元数据在solr中被索引（在同时写入的情况下）。
更新：按要求（在下面的评论），这里是DSpace如何执行更详细的索引（在SOLR）。
dspace有一个定义的事件系统。它遵循本节dspace.cfg中的配置：https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace/config/dspace.cfg#L732
默认情况下，在dSPACE 5中，IndexEventConsumer是执行SOLR的索引。默认情况下，在这里定义配置：https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace/config/dspace.cfg#L732
在dspace 5中，每当有人更改项的元数据（或任何有关项的内容）时，都会调用Item.update()方法将更改实际保存回数据库层。
保存所有更改（使用DatabaseManager.update()）后，Item.update()方法将生成new MODIFY event in the Event System。
新的修改事件被附加到LinkedList of events in the current Context
当Context is committed时（保存更改时发生），它首先调用db连接上的commit（结束事务）。然后，它将事件列表发送给dispatcher（BasicDispatcher在dspace.cfg中默认配置），然后在solr中触发索引（通过配置的IndexEventConsumer）
IndexEventConsumer将更新对象列表（在本例中是一个项目）传递给索引服务（默认情况下SolrServiceImpl）。
最后，SolrServiceImpl.indexContent()从数据库中读取最新的元数据值，并在solr中索引它们。
上面的逻辑仍然有点简单（因为它太复杂了，无法遍历代码的每一步）。但是，这里的基本要点是，每个Item.update()调用都被视为一个数据库事务。它还触发添加一个modify事件，该事件存储在用户的会话（上下文对象）中。一旦提交了db事务，modify事件将由IndexEventConsumer处理，后者将重新索引整个项。
因此，在同时编辑的情况下，将生成两个修改事件（每个编辑一个）。但是，在提交最后一次数据库编辑之前，不会触发最后一次修改事件。因此，solr索引应该始终与数据库中的最新信息同步。