java - (N)Hibernate "session-per-application"被认为是特定用例的邪恶？

Question

好的，每个人都知道不鼓励使用 (N)Hibernate 的全局 session 每个应用程序。但是我有一个非常具体的、显然是非标准的用例，它似乎是理想的解决方案。

总而言之，我的(服务器)应用程序的所有持久数据基本上都在内存中，并且从不查询数据库以进行正常操作。首先使用数据库的唯一原因是数据在进程的生命周期内存活。我只想在应用程序启动时查询数据库以将所有内容提取到内存中。实际上，该数据库只有大约 5-10 MB。

现在的问题是，如果我遵循 session 必须是短暂的建议，我必须为每个业务交易合并()我的所有数据，或者以某种方式手动跟踪所有更改，而不是利用 NHibernate 的自动更改跟踪。这使得持久性很难在不导致大量性能开销的情况下实现。

所以我的问题是，是否有任何理由不应该为这个特定用例使用全局 session ？

我所知道的反对全局 session 的常见论点:

1. 随着时间的推移，一级缓存将被整个数据库填满=> 我不介意，因为我实际上想要将所有数据都存储在内存中!

2. 过时的数据和并发问题=> 我的应用程序被设计成所有可以访问或修改持久数据的代码都必须是单线程的(故意的设计选择)，并且它是唯一可以写入数据库的应用程序。所以这应该不是问题。

3. 如果 session 抛出异常(例如数据库超时)， session 就会损坏=> 这是我能看到的唯一真正的问题，但可以通过丢弃 session 、创建新 session 并刷新所有数据来解决。代价高昂，但异常应该非常罕见，并且只能由重大错误或重大基础设施问题引起，这两者都应尽快解决。

所以我认为没有理由不为我的特定用例使用全局 session 。还是我遗漏了什么重要的东西？

更新 1:它是一个服务器应用程序

更新 2:这并不意味着长期的全局交易。交易仍然是短暂的 - 一个长期 session ，许多短期交易。

Answer 1

如果您扇入来自多个线程的所有事务到一个专用的后端线程执行器，那么您确实可以为每个应用程序使用一个 session 。

异常可能由锁定超时、服务器崩溃或违反约束触发，因此撤回支持 Session 将导致丢弃所有一级缓存条目，这对您的用例不利。在这种情况下，您将不得不从数据库中重新获取所有内容，并且因为您使用单个后端线程，所以所有其他客户端线程都将被阻塞，这是没有说服力的。

我建议您使用 second-level cache instead .您可以将 2LC 提供程序配置为在内存中存储所有内容，而不是溢出到磁盘。您可以在应用程序启动时加载二级缓存中的所有数据并使用 NONSTRICT_READ_WRITE Cache Concurrency Strategy加快写入速度(无论如何并发问题对您来说都不是问题)。

您需要确保使用 2NL caching for collections too .

最简单的设计是使用一个 session 一个请求，因为 session 无论如何都是轻量级的，而且它无论如何都会从内存中的 2LC 中获取数据。

您需要运行一些性能测试，看看是否值得重用 session ，而不是在每个事务中都创建一个新 session 。您可能会发现这个过程无论如何都不是您的瓶颈，您不应该在没有真实证据的情况下进行任何优化。

丢弃 session 的另一个原因是大多数与数据库相关的异常无论如何都无法恢复。如果服务器出现故障或当前请求引发约束冲突，则重新绑定(bind)它不会解决任何问题。