我们的设计有一个jvm，它是一个jboss / webapp(读/写)，用于通过休眠(使用jpa)将数据维护到数据库。该模型具有10-15个持久类，并在关系中具有3-5个深度级别。

然后，我们有一个单独的jvm，它是使用此数据的服务器。由于它持续运行，因此只有一个长数据库会话(只读)。

当前不涉及内部jvm缓存，因此我们手动向另一个jvm发送信号。

现在，当webapp更改某些数据时，它会向服务器发出信号以重新加载更改的数据。我们发现，我们需要告诉休眠状态清除数据，然后重新加载它。仅对数据库执行获取/合并操作并不能完成该工作，主要是针对层次结构下几层的对象。

关于此设计是否存在根本错误或者是否有人正在这样做的任何想法，并且最好在重新加载时使用休眠模式。

谢谢，

解决方案

回答

克里斯

克里斯，我对情况有些困惑。如果我理解正确，那么我们既有一个Web应用程序(读/写)，又有一个独立的应用程序(只读？)，它们都使用Hibernate访问共享数据库。我们对网络应用所做的更改对独立应用不可见。是对的吗？

如果是这样，我们是否考虑过使用其他二级缓存实现？我想知道我们是否能够使用由Web应用程序和独立应用程序共享的群集缓存。我相信与Hibernate集成的SwarmCache将允许这样做，但是我自己还没有尝试过。

回答

通常，尽管如此，我们应该知道给定缓存的内容永远不会知道其他应用程序的活动(这就是为什么我建议让两个应用程序共享一个缓存)。祝你好运！

Hibernate会话将从数据库读取的所有数据加载到他们所谓的第一级缓存中。从数据库加载行后，对于具有相同PK的行的任何后续提取都将返回此缓存中的数据。此外，Hibernate负责人在单个会话中引用具有相同PK的对象的相等性。

据我了解，只读服务器应用程序永远不会关闭其Hibernate会话。因此，当数据库由读写应用程序更新时，只读服务器上的会话不会意识到更改。实际上，只读应用程序正在加载数据库的内存中副本并使用该副本，该副本在适当的时候会过时。

我建议的最简单，最好的操作方法是根据需要关闭和打开会话。这回避了整个问题。休眠会话旨在成为与数据库进行短暂交互的窗口。我同意通过不一次又一次地重新加载对象图来提高性能。但我们需要对其进行衡量，并说服自己，值得付出痛苦。

另一个选择是定期关闭并重新打开会话。这样可以确保只读应用程序可以处理不超过给定时间间隔的数据。但是肯定有一个窗口，只读应用程序可以处理过时的数据(尽管设计保证了它最终会获取最新数据)。在我们需要评估状况的许多应用程序中，这可能是允许的。

回答

第三种选择是使用二级缓存实现，并使用短暂的会话。与Hibernate一起使用的缓存程序有很多，各有优缺点。

从我的角度来看，我们应该将下划线的Hibernate缓存更改为支持集群模式的缓存。它可能是JBoss缓存或者Swarm缓存。第一个对数据同步(复制和无效)有更好的支持，并且还支持JTA。

段落数量不匹配