为什么事务@Transactional会失效？深入剖析背后的原因

2023-09-17 17:55:45

揭秘@Transactional注解失效的内幕

在Java开发中，事务管理是一个至关重要的概念。作为一名技术人员，理解@Transactional注解在事务管理中的作用至关重要。但是，有时您可能会遇到@Transactional注解失效的情况，让您感到困惑。为了帮助您在面试中应对这个问题，本文将深入探讨@Transactional注解失效的潜在原因。

1.传播行为的陷阱

@Transactional注解的传播行为决定了事务在多个方法或类之间的传播方式。默认情况下，它使用REQUIRED传播行为，这意味着它将加入现有事务或创建一个新事务。但要注意以下特殊情况：

REQUIRES_NEW传播行为： 该传播行为总是创建一个新事务，即使存在当前事务。当前事务将被挂起，直到新事务完成。如果新事务抛出异常，当前事务不会回滚。
NOT_SUPPORTED传播行为： 该传播行为禁用当前事务，导致方法或类中执行的操作不属于任何事务。如果在此处抛出异常，当前事务也不会回滚。

2.隔离级别的影响

隔离级别决定了事务之间的可见性。默认的READ_COMMITTED隔离级别意味着事务只能看到已提交的数据。然而，其他隔离级别可能导致问题：

READ_UNCOMMITTED隔离级别： 事务可以看到未提交的数据，可能导致脏读。
SERIALIZABLE隔离级别： 事务按顺序执行，防止脏读和不可重复读，但代价是并发性降低。

3.回滚机制的困惑

默认情况下，@Transactional注解使用默认的回滚机制，即在异常情况下回滚事务。但是，有例外：

noRollbackFor属性： 可以指定特定异常不应导致事务回滚。
只读事务： 只读事务不会对数据库进行修改，因此即使抛出异常也不会回滚。

4.超时的风险

默认情况下，@Transactional注解没有超时机制。但是，可以通过timeout属性指定超时时间。如果事务在此时间内未完成，它将超时并回滚。

5.只读的限制

@Transactional注解的readOnly属性可以指定事务为只读。这意味着它不能对数据库进行修改。如果在只读事务中尝试修改，则会抛出异常。

6.嵌套事务的复杂性

@Transactional注解可用于嵌套事务。但是，嵌套事务的传播行为、隔离级别和回滚机制可能与父事务不同，从而导致意外结果。

7. JPA事务管理的差异

JPA的事务管理与Spring的事务管理类似，但有一些关键差异。JPA事务的传播行为和隔离级别可能与Spring不同，导致@Transactional注解失效。

8. 代码示例

为了进一步阐明这些概念，我们提供一个代码示例来说明@Transactional注解失效的情况：

@Transactional(propagation = NOT_SUPPORTED)
public void method1() {
  // ... 代码
}

@Transactional
public void method2() {
  method1(); // 由于method1禁用了事务，method2中的事务不会回滚
}