与主数据模块的插入/更新/删除相比，读取操作非常高。到目前为止，我们正在使用JDBC进行读取，写入和更新操作。我们正在删除操作上进行软删除（将IS_DELETED列标记为'Y'）。所有写入/更新方法都是同步的，以处理concurreny。我们正在使用oracle，并且没有计划支持多个数据库。
现在，我们正在计划缓存数据，我们还计划进行群集。
我们最简单的选择是更改插入/更新/删除方法，并使用类似ehcache的方法根据我们的要求管理缓存，并使用表中的版本列处理集群环境中的并发，并删除synchronized关键字。
我周围的人建议的其他选项（Infact要求我这样做）是转移到hibernate（我不太了解hibernate），它将自动处理缓存和并发。
以下是我的疑惑：
1）是否值得更改完整的DAO代码，因为我们有大约200个表来管理主数据？
2）在这种情况下，我们需要再次过滤缓存的数据以丢弃已删除的行，或者有一种hibernate（或任何其他方式）的机制，我们可以在数据库中执行更新操作但是会暂停二级缓存帮助删除缓存数据中的操作？
3）我们已将数据传输对象暴露给具有表的所有字段的其他模块，其中主键存储在单独的PK对象中（在单独的对象中具有主键字段），并且我们没有引用DO它（复合DO不在那里）。鉴于，我们不能改变暴露的方法和DO结构 - 所以我们必须再次在我们的DO中打包hibernate缓存的实体数据吗？或者我们可以将旧的DO结构重用为hibernate实体（根据我的理解PK列应该直接在hibenate实体中存在而不是在某个复合对象中）。我提到了复合DO，因为我们还有依赖的下拉要求，如果我们首先使用复合DO，它可以用于子对象的hibernate延迟加载。反对的论点是提供使用缓存数据和描述旧方法的新方法。其他模块会根据缓存的需要慢慢迁移，但我们会维护问题，因为我们必须在db更改的情况下维护这两种方法。此外，还有1和2个疑点。
我确信在这个阶段hibernate不是我们的方式，我必须说服我周围的人，但我想知道你对除了自动管理二级缓存之外的移动到休眠的长期优势的看法，并发处理（我们可以通过常见的小代码更改完成）和db indepedency（我们不感兴趣）更改完整代码的成本。
答案 0 :(得分：1)
如果你计划迁移到休眠，你应该考虑到 1）您需要将所有结构映射到POJO（如果您还没有） 2）重写所有DAO以使用hibernate（请记住，hibernate QL / criteria API有一定的局限性 3）准备好对抗延迟初始化问题等等...... Personaly我不认为值得用工作模式迁移到休眠状态，除非维持当前模型非常痛苦
关于你的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结构。
希望有所帮助