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