Hibernate事务有多复杂

Question

这可能更像是一个“设计”或风格问题：我刚刚考虑过Hibernate事务应该或可能有多复杂。我正在使用一个应用程序，使用Hibernate将消息持久化到数据库。

构建消息POJO涉及将消息中的一对多关系分解为各自的持久对象。例如，消息包含“城市”字段。从消息中提取城市，数据库搜索等效的城市对象，并将结果对象添加到消息POJO中。所有这些都是在一次交易中完成的：

• 开始交易
• 测试重复
• 检索城市对象
• 邮件对象中的setCity（cityObject）
• retreive country object
• 邮件对象中的setCountry（countryObject）
• 持久消息对象
• 提交结束交易

事实上，实际交易要复杂得多。这是一个合理的结构还是应该在一个事务中完成每个任务（而不是一个事务中的所有任务）？我想第二个问题涉及在交易中设计任务的最佳实践。我知道有些任务需要针对参照完整性进行分组，但情况并非总是如此。

Answer 1

交易应根据业务要求进行分组，而不是技术复杂性。如果你有N个操作必须作为一个单元一起成功或失败，那么代码应该支持的是什么。它应该更多地是商业考虑而不是技术考虑。

Answer 2

无论你在外部交易边界内放置什么，问题在于你是否能成功回滚每一个动作。

在边界内捆绑相关的操作，并尽可能简单。

Answer 3

如果数据库之间没有处于愚蠢状态，那么多个事务才有意义，因为任何单个事务都可能失败。如果任何活动块必须是原子的并且整个事务依赖于任何其他原子单元，则嵌套事务可能有意义。