应用错误收集

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

Q2。有几种缓存是可能的。

但是，数据库存在问题缓存是它在物理上的数据库服务器，所以每个查询涉及网络呼叫（延迟，带宽..）。这就是重点应用程序中的缓存服务器

Hibernate L2缓存有一些细节：
- 非常容易使用（无代码，少量配置）
- 从概念上讲，在实体层面（相当细粒度，我们有时需要缓存更大的粒度，以减少数据库请求），
- 通过id或集合工作（例如，默认情况下，缓存查询结果的缓存，因为在一般情况下无法使其有用）。

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

在分布式环境中，这经常发生转化为无效的他们中的一个时的类别实体被修改，这是功能上的对我们来说是合乎逻辑的表现，否则我们会必须使所有这些无效实体;这是因为缓存使整个区域无效，或者a 特定的对象，但在你必须循环，这对性能不利）

其他人我肯定......

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

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

你也可以使用[Infinispan（JBoss Cache的演变）作为二级缓存提供商！] [1]

EhCache有一个分布式模式，但我不确定Hibernate是否支持它。但我不明白为什么它不应该起作用。

您是否出于某些特定原因省略了JBossCache 3？

hibernate-redis lib将是完美的选择。这是一个基于Redis的缓存。

为何选择Redis？它非常快速，可以在云中运行，并且具有像AWS Elasticache这样的现成云解决方案，因此您无需自己管理它。