几个关系数据库表由驻留在进程中的单个对象缓存管理。当缓存被提交时，表被更新。DB 关系表由常规 SQL 查询更新，而不是像 hibernate 这样更花哨的东西。
最终，其他进程在不相互通信的情况下进入了修改该对象的业务，即，每个进程将初始化该对象（从 DB 读取）并更新它（提交到 DB），而其他进程将不知道它坚持到过时的缓存。
我必须修复这个工作流程。我想到了几种方法。一种是使这个对象成为一个mBean。因此，对象将驻留在一个进程上，并且每个进程最终都会通过 mBean 方法调用修改该进程中的对象。
然而，这种方法有几个问题。1) 此缓存返回的每个对象都是一个 mBean，这可能会使方法调用变得非常冗长。2）还要求每个进程都应该看到数据库的一致数据模型（缓存），并且如果可能的话，它应该将其内容合并到数据库中。（如交易）。如果数据库被其他进程显着更新，则合并失败是可以的。
Java中的哪些技术将有助于解决这个问题？
你应该看看兵马俑。他们拥有使多个 JVM（可以在不同的服务器上）看起来统一的技术。如果您在一个 JVM 上更新一个对象，Terracotta 将以一种安全的方式在集群中的所有 JVM 上透明地更新该实例。
我同意约翰的观点——在休眠中使用支持集群的二级缓存。通过使用简化的数据访问模型并让 Hibernate 管理细节来更直接地管理数据。
Terracotta Ehcache 就是这样一种缓存，JBoss、Coherence 等也是。
有关Hibernate 二级缓存的更多信息可以在此处和第 19 章的官方 Hibernate 文档中获得。 提高性能（请注意，虽然 Hibernate 文档确实列出了二级缓存提供程序，但该列表已经过时了，例如谁使用Swarm Cache？最后一次发布是在 2003 年）
如果要保留对象模型，可以在提交之前使用java 对象缓存进行集中存储。或者您可以使用zookeeper保持共享锁。
但听起来你真的应该放弃自我管理的缓存。使用您提到的休眠或其他JPA实现。JPA 解决了缓存问题并维护了 L2 共享缓存，因此他们已经为您考虑了这一点。