Spring中@Transactional事务回滚失效问题排查（附控制器代码）

Hey there, let's break down why your @Transactional(rollbackFor = RuntimeException.class) annotation isn't triggering a rollback in the cancelRefundApplication method. Here are the key areas to investigate:

1. Controller-layer transactions aren't always reliable (Spring's default behavior) #

Spring's transaction management is designed to work best at the Service layer, not the Controller layer. By default, Spring MVC controllers are managed by the DispatcherServlet, and the transaction proxy might not properly enhance controller beans. Even if you add @Transactional to a controller method, it might not be picked up by Spring's transaction interceptor.

Fix suggestion: Move the transaction logic to a dedicated Service layer method (e.g., OrderService.cancelRefundApplication(...)), add the @Transactional annotation there instead, and call that service method from your controller. This follows standard Spring architecture and ensures the transaction proxy works as expected.

2. Exception is being caught and swallowed, or isn't a RuntimeException #

Your annotation specifies rollbackFor = RuntimeException.class, which means only unchecked exceptions (subclasses of RuntimeException) will trigger a rollback. If:

• The code in service.getOrderByID(...) or refundService methods throws a checked exception (like SQLException, IOException), the transaction won't roll back unless you add those exceptions to rollbackFor.
• You have a try-catch block inside cancelRefundApplication that catches the exception without re-throwing it, Spring's transaction manager won't detect the error and won't trigger a rollback.

Check: Look at the full code of cancelRefundApplication—make sure any exceptions from your service methods are propagated up (not swallowed) and that they are RuntimeException instances (or adjust the rollbackFor attribute to include the checked exceptions you need).

3. Missing transaction management configuration #

Spring won't process @Transactional annotations unless you explicitly enable transaction management. Verify that:

• Your Spring configuration class has the @EnableTransactionManagement annotation.
• If you're using XML configuration, you have <tx:annotation-driven/> in your context file.
• You have a transaction manager bean defined (e.g., DataSourceTransactionManager for JDBC/JPA) that Spring can use to manage transactions.

4. Bean injection issues #

Check if your OrderService and RefundService beans are being injected correctly as Spring-managed proxies. If:

• You're not using dependency injection (e.g., instantiating service with new OrderService() instead of letting Spring inject it), the service methods won't be transactional, and any changes they make won't be part of your controller's transaction.
• Your controller isn't a Spring-managed bean (though you have @RestController, so this is unlikely—double-check that your component scan includes the package containing OrderController).

5. Transaction propagation behavior conflicts #

If the service or refundService methods have their own @Transactional annotations with conflicting propagation behaviors, this could prevent rollback. For example:

• If a service method uses PROPAGATION_REQUIRES_NEW, it will run in a separate transaction that won't be rolled back when your controller's transaction fails.
• If a service method uses PROPAGATION_SUPPORTS, it won't join an existing transaction unless one is already active.

Check: Review the transaction annotations on your service methods to ensure their propagation settings align with your expected rollback behavior.

内容的提问来源于stack exchange，提问作者AlpacaMan