3

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

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

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

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

4

3 回答 3

4

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

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

于 2009-03-08T23:02:25.403 回答
2

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

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

于 2009-03-09T00:25:51.663 回答
0

我更倾向于纯粹主义者，但我尝试在数据库本身内部保留任何和所有事务管理，而不是简单的自动提交。大多数数据库都非常擅长处理事务管理，毕竟，它是数据库要做的关键组件之一。

于 2009-03-09T00:05:08.360 回答