群集上的Hibernate L2 Cache

Question

Q1:我是对的,只有这些供应商支持集群上的Hibernate L2缓存吗？

Q2:Hibernate L2缓存有什么替代品吗？(也许有些DB缓存？)

Answer 1

Q1.EhCache可以很好地分发Hibernate L2 Cache.我们正在将此用于我们的项目.

Q2.几个缓存是可能的.

但是,数据库缓存的问题在于它在物理上位于数据库服务器上,因此每个查询都涉及网络调用(延迟,带宽...).这就是应用服务器上缓存的重点.

Hibernate L2缓存有一些细节:
- 非常容易使用(没有代码,很少配置)
- 从概念上讲,在实体层面(这是非常细粒度的,我们有时需要缓存更大的粒度,以减少数据库请求),
- 通过id或集合工作(例如,默认情况下,缓存查询结果的缓存,因为在一般情况下不可能使其有用).

当Hibernate L2不合适时,我们使用相同的EhCache库来缓存数据(这不是完全实体).用例示例:
- 当一个表很大(记录长度和数量)时,内存使用不允许完全缓存它,但是只缓存所有记录的三个字段是可以的.可能是这些字段是经常访问的字段,或者是不可变的......
- 当我们对缓存有很多读访问时,每个都会在给定我们拥有的实体的情况下触发计算(在L2缓存上):计算结果可以存储在缓存中.(典型的例子,其中计算需要来自其他表的详细信息,但详细信息未在最终结果中使用,因此缓存不存储这些详细信息)
- 当表中的实体按类别进行逻辑分组时,我们希望一次请求和缓存一个类别,而不是一次只能是一个实体的常规L2缓存策略.

在分布式上下文中,这通常转化为在修改其中一个实体时使类别无效,这对我们来说在功能上是合乎逻辑的(对性能至关重要,否则我们将不得不使所有这些实体无效;这是因为缓存使整个区域或特定对象无效,但在两者之间必须循环,这对性能不利)

和其他人我敢肯定......

所以这种情况与数据库无关,它通常不存储我们的Hibernate实体.我们将其放在业务层(而不是数据访问或Daos)中,使其直接可用于业务代码.请注意,对于我们来说,它不是透明缓存,而是对显式业务服务的调用(负责此缓存:如果数据不存在则加载它,根据需要使其无效)执行操作或传递值.

这个缓存中一个有趣的线程问题:因为我们的百个Web线程访问了这个缓存,所以它需要是线程安全的.您可能知道为什么线程安全值在每次调用时都是不可变的或克隆的(这通常是性能问题).因此,我们所有的业务缓存都使用不可变对象,性能也很好.