我们有一个读取和写入第三方数据存储的应用程序。该数据存储的代码是闭源的，我们不知道也无法更改。只有一个苗条的 API 允许对其进行读写。
悲观的离线锁有助于跨越事务并让并发应用程序使用它。我相信这会很好。
但是现在我们遇到的问题是其他软件也会对该存储进行写入和读取，并且当该数据存储发生更改时，我们的应用程序将更新。数据存储本身不提供任何通知。第三方软件不会改变一些全局状态，表明某些东西已经改变。
是否有任何模式或最佳实践来“观察”数据存储并发布事件以更新（我们软件的）所有客户端？
如果不是万不得已，我真的不想定期阅读、比较和发布事件。也许有人在这里有更好的主意？
非系统实现的悲观离线锁需要所有可能的数据修改者之间的合作/参与/执行。这通常是不可能的，这是现代软件中很少采用这种方法的两个原因之一。要以一种有用的方式远程执行这样的操作（即，使用多个异构编写器）需要系统设施本身的某种帮助/协助。（第二个原因是确定和解决废弃锁的问题，非常成问题）。
至于可能的解决方案，那么从纯粹的设计角度来看，要么是乐观的离线锁，它仍然需要一些系统帮助，但要少得多，或者通过数据模型中更详细的状态进展/控制来完全避免这个问题。
然而，我的方法是（最初）搁置设计问题，认识到这主要是数据存储功能的问题，并从那里开始，寻求使用系统提供的锁定/事务控制，（两者都是 1：通常有效，2：通常是如何完成的）。
AFAIK，同步多写入器访问的问题始终必须从“哪些工具/控件/设施可用于约束、转移和/或跟踪应用程序外写入器？ ”您可以完成的工作实际上受到这些设施的限制.
例如，如果您可以通过自己的服务强制所有访问，那么您几乎可以做任何事情。但是，如果您只有操作系统的文件锁定和文件修改日期，那么您将受到更多限制。如果你连那个都没有，那么你也无能为力。
事实上，我没有直接访问数据存储的权限，它托管在某个服务器上，我无法控制读取和写入它的其他应用程序。现在，我能想到的最好的方法是提供一个服务作为代理，它定期查询商店，将其与旧状态进行比较，如果其他应用程序更改了它，则向我的客户端触发更新事件（如果我的应用程序更改它以通知我自己的客户，让其他应用程序有自己的问题）。这对我来说听起来不是很好，但它可能完成了这项工作。
是的，这就是你所能做的，并且只支持乐观并发（部分），不支持悲观。您可能会通过向存储的数据添加某种校验和/哈希来获得改进，但这只是一种优化。