第三方并发写者的“悲观离线锁”

Question

我们有一个可以读写第三方数据存储的应用程序。 该数据存储的代码是闭源的，我们不知道也无法更改。 只有一个纤薄的 API 允许对其进行读写。

pessimistic offline lock 有助于跨越事务并让并发应用程序使用它。我相信这会很好。

但是现在我们遇到了其他软件也会对该存储进行读写的问题 当数据存储发生变化时，我们的应用程序将更新。数据存储本身不提供任何通知。第三方软件不会改变一些全局状态，表明某些东西已经改变。

是否有任何模式或最佳实践来“观察”该数据存储和 发布事件以更新（我们软件的）所有客户端？

如果不是，我真的不想定期阅读、比较和发布事件 绝对是最后的手段。也许有人在这里有更好的主意？

Answer 1

非系统实现的悲观离线锁需要所有可能的数据修改者之间的合作/参与/执行。这通常是不可能的，这是现代软件中很少采用这种方法的两个原因之一。要以一种有用的方式远程做任何这样的事情（即，与多个异类编写者），需要系统设施本身的某种帮助/协助。 （第二个原因是确定和解决废弃锁的问题，非常成问题）。

至于可能的解决方案，那么从纯粹的设计角度来看，要么是乐观的离线锁，它仍然需要一些系统帮助，但要少得多，或者通过数据模型中更详细的状态进展/控制来完全避免这个问题。

然而，我的方法是（最初）搁置设计问题，认识到这主要是数据存储功能的问题，并从那里开始，寻求使用系统提供的锁定/事务控制，（ 1：通常有效，2：通常是这样）。

AFAIK，同步多写入器访问的问题始终必须从“哪些工具/控件/设施可用于约束、转移和/或跟踪应用程序外写入器？”开始您可以完成的工作实际上受到这些设施的限制。

例如，如果您可以通过自己的服务强制所有访问，那么您几乎可以做任何事情。但是，如果您只有操作系统的文件锁定和文件修改日期，那么您将受到更多限制。如果你连这个都没有，那么你也无能为力。

事实上，我没有直接访问数据存储的权限，它托管在 一些服务器，我无法控制其他应用程序 读取和写入它。现在，我能想到的最好的就是拥有一个 服务作为定期查询商店的代理，比较它 到较旧的状态，如果有其他情况，则向我的客户触发更新事件 应用程序已更改它（如果我的 应用程序更改它以通知我自己的客户，留下另一个 应用程序有自己的问题）。对我来说听起来不太好， 但它可能完成了这项工作。

是的，这就是你所能做的，并且只支持乐观并发（部分），不支持悲观。您可能会通过向存储的数据添加某种校验和/哈希来获得改进，但这只是一种优化。