您会使用 AOP 进行数据库事务管理吗？答案

【问题标题】：Would you use AOP for database transaction management?您会使用 AOP 进行数据库事务管理吗？
【发布时间】：2010-10-12 02:06:35
【问题描述】：

不久前，我编写了一个应用程序，它使用Spring AOP 来定义哪些方法是事务性的。我现在正在重新考虑这是一个多么棒的想法。在一次小的重构（更改方法签名等）之后，我被击中了几次，这当然不会变得明显，直到实际出现问题（并且我有一个逻辑上不一致的数据库）。

所以我对一些事情感兴趣：

其他人是否决定恢复到显式事务管理（例如通过@Transactional 注释）？
我可以在构建过程中使用哪些有用的工具来帮助确定是否有任何东西“损坏”了？
如果人们使用 AOP 来管理事务，他们会采取哪些步骤来避免我所犯的错误？

我正在使用 IntelliJ IDEA，它允许您浏览修饰方法，并将重构 Spring XML 配置以及方法名称更改，但这并不总是足够的（将参数添加到错误位置的方法会影响是否例如，一个方面会触发）

【问题讨论】：

标签： java database spring transactions aop

【解决方案1】：

我目前在我从事的两个 Java 项目中使用声明式事务管理，通过 @Transactional 注释指定哪些方法需要事务范围。在我看来，它是灵活性和健壮性的完美结合：您可以通过简单的文本搜索查看哪些方法具有事务行为，如果需要可以手动调整隔离和传播属性，并且额外的输入量实际上是可以忽略的.

在其中一个项目中，我通过方面实现了安全/日志记录，并且在重命名方法或更改签名时偶尔会遇到与您相同的障碍。在最坏的情况下，我丢失了一些用户访问合约的日志数据，并且在一个版本中，一些用户角色无法访问所有应用程序功能。没什么大不了的，但是，就数据库事务而言，我认为这根本不值得，我最好自己输入@Transactional bit。无论如何，Spring 是最困难的部分。

【讨论】：

+1 - 在 Spring 2.5 中利用注释是个好建议。
我最初没有这样做的原因是，通常业务逻辑必须是事务性的，而不是单独的持久性调用。我不希望到处都是 Spring 导入 - 我希望尽可能隔离持久性实现细节
对，这就是为什么@Transactional注解属于服务层，而不是持久层。事务是关于用例中的工作单元，由服务表示。
是的——但是服务层可能有几十个接口。我不想在所有这些中引入对 Spring 的依赖。不过我想我现在已经软化了
我总是将@Transactional 放在接口（服务）实现上，而不是放在接口本身上。这些实现甚至是单独打包的。因此，像 UserManager 这样的接口只导入域/业务对象，而 UserManagerImpl 具有 Spring 和 Hibernate 依赖项。

【解决方案2】：

关于（1）：在过去几年的所有项目中，我发现@Transactonal 是一个更实用的解决方案。然而，在一些非常特殊的情况下，我还必须使用 Spring AOP 来允许使用多个 JDBC 连接/TransactionManager，因为@Transaction 绑定到单个事务管理器。

关于（2）：话虽如此，在混合场景中，我进行了大量自动化测试以查找可能损坏的代码。我使用 Spring 的 AbstractTransactionalJUnit4SpringContextTests / AbstractTransactionalTestNGSpringContextTests 来创建我的测试。到目前为止，这是一个非常有效的解决方案。

【讨论】：

【解决方案3】：

我更倾向于更纯粹，但我尝试将所有事务管理保留在数据库本身内部，而不是简单的自动提交。大多数数据库在处理事务管理方面都很出色，毕竟，它是数据库要做的关键组件之一。

【讨论】：

数据库还在做。您如何通过这种安排管理两阶段提交？必须有一个了解所有玩家的第 3 方，那就是中间层事务管理器。
完全正确 - 正确执行此操作的唯一方法是将业务逻辑移动到数据库中。例如，insert-transaction/update-account 必须“加入”在一起，否则最终会出现原子性问题
你没有提到两阶段提交。您简单地说数据库事务管理，这比两阶段提交要容易得多。如果你需要 2PC，Spring 的 @Transactional 也帮不了你。