java - Hibernate二级缓存以防软删除

Question

与主数据模块的插入/更新/删除相比，读取操作非常高。到目前为止，我们使用 JDBC 进行读、写和更新操作。我们正在对删除操作执行软删除(将 IS_DELETED 列标记为“Y”)。所有写入/更新方法都是同步的以处理并发。我们使用的是oracle，没有计划支持多个数据库。

现在，我们计划缓存数据，并且还计划进行集群。

我们最简单的选择是更改插入/更新/删除方法，并使用 ehcache 之类的东西根据我们的要求管理缓存，并通过使用表中的版本列并删除同步关键字来处理集群环境中的并发性。

我周围的人建议的其他选择(事实上要求我做)是转移到 hibernate (我对 hibernate 不太了解)，它将自动处理缓存和并发。

这是我的疑问:

1) 鉴于我们有大约 200 个表来管理主数据，是否值得更改完整的 DAO 代码？

2)在这种情况下，如果我们需要再次过滤缓存数据以丢弃已删除的行，或者 hibernate 中有一种机制(或任何其他方式)，我们可以在数据库中执行更新操作，但在缓存数据中执行删除操作，那么 hibernate 二级缓存会有所帮助吗？

3) 我们已将数据传输对象暴露给其他模块，其中主键表的所有字段存储在单独的 PK 对象中(主键字段位于单独的对象中)，并且其中没有引用 DO(不存在复合 DO)。鉴于，我们无法更改公开的方法和 DO 结构 - 那么我们是否必须再次将 hibernate 缓存的实体数据打包到我们的 DO 中？或者我们可以重用旧的 DO 结构作为 hibernate 实体(根据我的理解，PK 列应该直接存在于 hibenate 实体中，而不是存在于某个复合对象中)。我提到复合 DO 是因为我们还有依赖的下拉需求，如果我们首先拥有复合 DO，则可以将其与子对象的 hibernate 延迟加载一起使用。反对的论点是提供使用缓存数据的新方法并贬低旧方法。其他模块会根据缓存的需要慢慢迁移，但我们会遇到维护问题，因为我们必须在数据库更改的情况下维护这两种方法。另外，1和2疑点仍然存在。

我确信 Hibernate 不是我们现阶段的最佳选择，我必须说服我周围的人，但我想知道您对迁移到 Hibernate 的长期优势的看法，除了自动管理二级缓存、并发处理(我们可以通过在常见位置进行小的代码更改来完成)和数据库独立性(我们不感兴趣)更改完整代码的成本。

Answer 1

如果您计划迁移到 hibernate 模式，您应该考虑1)您需要将所有结构映射到 POJO(如果还没有)2)重写所有DAO以使用hibernate(请记住，hibernate QL/criteria API有一定的限制3)准备好应对延迟初始化问题等等......就我个人而言，我认为不值得将工作模型迁移到 hibernate 状态，除非维护当前模型非常痛苦

关于你的第2和第3个问题2) 二级缓存仅保存已加载的实例，通过主键访问。即，如果您说 hibernateSession.load(User, 10) - 它将使用 id=10 在二级缓存中查找 User 对象。如果我清楚地理解的话，情况并非如此。大多数时候，您希望使用更复杂的查询加载数据 - 在这种情况下，您将需要 StandarQueryCache，它将您的查询字符串映射到加载的 ID 列表，而这些 ID 又将从二级缓存中检索。但是如果你有很多相似度较低的查询 - StandartQueryCache 和二级缓存都将毫无用处(看看 http://darren.oldag.net/2008/11/hibernate-query-cache-dirty-little_04.html )3)您可以使用组件等，但我不确定您的DTO结构。

希望有帮助