是否总是在休眠状态下使用二级缓存?

先让它工作,然后再让它快点。如果不需要缓存,就不要实现它。

在我所使用的应用程序中,数据库是在多个应用程序之间共享的,其中一些根本不是Java。因此,在这些情况下,二级缓存对我来说不是一个选项,因为我不知道其他应用程序何时可以更新数据库。

我对Hibernate的使用总是在另一个框架(例如Spring)的上下文中进行的,在这个框架中启用缓存几乎是微不足道的。这些项目中的许多都使用了通过 ehcache 对于一些关键的域类。

尽管如此,这是另一个我们必须在资源之间进行权衡的领域——平衡检索性能和内存使用。没有测量的优化一次又一次被证明是糟糕的实践。

收集有关应用程序性能的指标。然后决定如何解决慢点。缓存可能是你最不担心的事情。

如果你做的对(注意选择n+1等),对于绝大多数情况,没有二级缓存的性能应该是可以接受的。

我们首先不使用它,只在性能下降时使用它。

引用著名的Donald Knuth的话:“程序员浪费大量的时间去思考或担心他们程序中非关键部分的速度,而在考虑调试和维护时,这些提高效率的尝试实际上具有很强的负面影响。我们应该忘记小效率,比如说97%的时间:过早的优化是万恶之源。然而,我们不应该在关键的3%中放弃我们的机会。”

如果您看到性能问题,只有这样您才能开始优化。而且,您应该只优化最大的瓶颈,并在需要时一路工作下去。

然而,在NHibernate中实现这种优化对调试和维护的影响在大多数情况下是微乎其微的,并且通常可以在代码中添加极少的内容来实现。

如果您广泛依赖于延迟加载,拥有只读表,不必担心与不使用nhibernate的应用程序的并发性,性能是一个问题,并且您了解如何使用二级缓存进行优化(这意味着您已经知道这个问题的答案),那么您应该使用二级缓存。

现在有一个与此相关的休眠特定问题。以及臭名昭著的lazyinitializationException。基本上,当实体附加到持久性上下文时,需要初始化所有的惰性关联。有两种方法可以做到这一点:

1. 手动访问关系以强制加载它们。
2. 使用指定join fetch的查询。

这两种方法会产生完全不同的代码段,因此将一个代码段迁移到另一个代码段可能是一项相当大的工作。问题在于方法1。在不使用二级缓存时会导致大量查询,因此人们可以决定使用方法2,这会导致发热查询。但是,当您稍后打开二级缓存时,方法2中的查询不会从缓存中加载数据,但会将结果实体放入其中,使查询执行速度比没有缓存时慢。这会导致一些复杂的事情,比如必须使用查询缓存。

正因为如此,我(在这个特定的例子中)似乎更适合首先为所有的实体启用缓存,这通常是微不足道的,然后在开发过程中为不需要缓存的实体禁用缓存。