【发布时间】：2011-10-14 10:51:37
【问题描述】：
与主数据模块的插入/更新/删除相比，读取操作非常高。到目前为止，我们使用 JDBC 进行读、写和更新操作。我们正在对删除操作进行软删除（将 IS_DELETED 列标记为“Y”）。所有写入/更新方法都同步以处理并发。我们正在使用 oracle，并且没有计划支持多个数据库。
现在，我们正在计划缓存数据，并且我们也计划进行集群。
我们最简单的选择是更改插入/更新/删除方法，并根据我们的要求使用 ehcache 之类的东西来管理缓存，并通过使用表中的版本列和删除同步关键字来处理集群环境中的并发。
我周围的人建议的其他选择（实际上是让我这样做）是转移到休眠状态（我不太了解休眠状态），它将自动处理缓存和并发。
这是我的疑问：
1) 考虑到我们有大约 200 个表来管理主数据，是否值得更改完整的 DAO 代码？
2) 在这种情况下，休眠二级缓存会有所帮助，因为我们需要再次过滤缓存的数据以丢弃已删除的行，或者休眠（或任何其他方式）中有一种机制可以通过它在数据库中执行更新操作，但是缓存数据中的删除操作？
3) 我们已将数据传输对象暴露给其他模块，该模块的所有主键字段都存储在单独的 PK 对象中（在单独的对象中具有主键字段），并且我们没有参考 DO它（复合 DO 不存在）。鉴于，我们不能改变暴露的方法和 DO 结构 - 那么我们是否必须再次将休眠缓存的实体数据打包到我们的 DO 中？或者我们可以将旧的 DO 结构重用为休眠实体（根据我的理解 PK 列应该直接在休眠实体中，而不是在某个复合对象中）。我提到复合 DO 是因为我们也有相关的下拉要求，如果我们首先有复合 DO，则可以将其与子对象的休眠延迟加载一起使用。反对的论点是提供将使用缓存数据并贬低旧方法的新方法。其他模块将根据缓存需要缓慢迁移，但我们将遇到维护问题，因为我们必须在数据库更改的情况下维护这两种方法。另外，还有1和2的疑惑。
我确信在这个阶段休眠不是我们要走的路，我必须说服我周围的人，但我想知道你对迁移到休眠的长期优势的看法，而不是自动管理二级缓存，并发处理（我们可以通过在公共地方进行小的代码更改来完成）和数据库独立性（我们不感兴趣）更改完整代码的成本。
【问题讨论】：
-
还有一点需要考虑：通过hibernate更新或插入数据到db不能批量完成。如果您需要使用一个查询更新多个数据集，则必须使用本机查询。为了获得数据集的当前版本，您必须清除二级缓存。