0

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

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

  • 开始交易
  • 重复测试
  • 检索城市对象
  • 消息对象中的 setCity(cityObject)
  • 检索国家对象
  • 消息对象中的 setCountry(countryObject)
  • 持久化消息对象
  • 提交结束事务

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

4

3 回答 3

1

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

于 2012-06-14T12:38:15.550 回答
1

无论您在外部事务边界内放置什么，问题是您是否可以成功回滚每个操作。

将相关操作捆绑在一个边界内，并使其尽可能简单。

于 2012-06-14T12:39:11.897 回答
1

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

于 2012-06-14T12:41:19.377 回答