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