Spring事务的传播行为有哪些？请列举并说明。

八股文_Spring面试题 0 20

参考回答

Spring事务的传播行为（Transaction Propagation）定义了事务方法在调用其他事务方法时，如何与当前事务交互。传播行为的选择决定了当前事务的方法是否加入到已有事务中，或是创建一个新事务。Spring支持七种事务传播行为，常见的传播行为如下：

Propagation.REQUIRED（默认）
- 作用：如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新事务。
- 适用场景：这是最常见的传播行为。通常用于绝大多数业务操作中，确保事务的一致性和原子性。
示例：
```
@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
   // 如果没有事务，会新建一个事务；如果有事务，加入现有事务
}
```
Java
Propagation.REQUIRES_NEW
- 作用：无论当前是否存在事务，都会新建一个事务，并挂起当前事务。新事务完成后，原事务继续执行。
- 适用场景：适用于必须在独立事务中执行的操作，不希望当前事务的状态影响到新的操作。例如，一些操作需要在新的事务中处理，而不受外部事务的影响。
示例：
```
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodB() {
   // 无论是否有事务，都会新建一个事务，挂起当前事务
}
```
Java
Propagation.SUPPORTS
- 作用：如果当前存在事务，则加入该事务；如果当前没有事务，则不启动事务。
- 适用场景：适用于某些操作不一定需要事务，但如果外部事务存在，则参与其中。例如，一些查询操作可能不需要事务，但在有事务的上下文中，仍然希望共享事务资源。
示例：
```
@Transactional(propagation = Propagation.SUPPORTS)
public void methodC() {
   // 如果有事务，加入事务；如果没有事务，则不使用事务
}
```
Java
Propagation.NOT_SUPPORTED
- 作用：如果当前存在事务，则挂起当前事务；如果当前没有事务，则不启动事务。
- 适用场景：适用于那些不需要事务管理的操作，比如某些需要排除在事务之外的操作，或者不需要保证原子性的数据处理操作。
示例：
```
@Transactional(propagation = Propagation.NOT_SUPPORTED)
public void methodD() {
   // 挂起当前事务，且不启动新事务
}
```
Java
Propagation.MANDATORY
- 作用：要求当前方法必须在一个已存在的事务中执行。如果当前没有事务，则抛出异常。
- 适用场景：适用于那些只能在事务内运行的操作，如果没有外部事务，当前操作不应当被执行。
示例：
```
@Transactional(propagation = Propagation.MANDATORY)
public void methodE() {
   // 必须在已有事务中执行
}
```
Java
Propagation.NEVER
- 作用：要求当前方法不能在事务中执行。如果当前存在事务，则抛出异常。
- 适用场景：适用于那些绝对不应在事务中执行的操作，防止事务管理干扰。
示例：
```
@Transactional(propagation = Propagation.NEVER)
public void methodF() {
   // 当前方法不能在事务中执行，如果有事务会抛出异常
}
```
Java
Propagation.NESTED
- 作用：如果当前存在事务，则在当前事务中创建一个嵌套事务（子事务），并支持回滚。子事务的回滚不会影响外部事务，除非外部事务本身回滚。只有在支持保存点的事务管理器中有效。
- 适用场景：适用于需要在当前事务中执行多个独立的操作，但如果子事务失败，只回滚该子事务而不影响整个事务。例如，进行复杂的分步操作时，某一部分失败时可以回滚该部分操作，而保留其他部分。
示例：
```
@Transactional(propagation = Propagation.NESTED)
public void methodG() {
   // 如果有事务，则在当前事务中创建子事务（嵌套事务）
}
```
Java

详细讲解与拓展

REQUIRED：
- REQUIRED是最常用的传播行为，它会加入到现有的事务中，或在没有事务时创建一个新的事务。这样可以确保方法间的事务共享，维护一致性。对于大多数业务逻辑，我们都希望它们在一个统一的事务上下文中执行，这样可以确保事务的一致性和原子性。
示例：
在金融系统中，当进行转账操作时，REQUIRED传播行为能确保扣款和存款操作都在同一个事务中执行，如果出现问题，整个转账操作会回滚。
REQUIRES_NEW：
- REQUIRES_NEW用于创建一个新的事务并挂起当前事务。当你希望某些操作即使外部事务失败也能执行时，可以使用此传播行为。比如，当你有独立的日志记录、审计操作时，可能希望它们在独立事务中执行。
示例：
假设我们在转账过程中记录审计日志，不论转账操作是否成功，审计日志都必须保存。此时，可以在日志记录操作上使用REQUIRES_NEW传播行为，确保即使转账失败，日志记录依然能成功提交。
MANDATORY：
- MANDATORY适用于需要依赖外部事务的场景。调用的方法只有在存在外部事务时才会执行，如果没有事务，就会抛出异常。这个传播行为确保了执行的操作必须要有外部事务支持，防止错误地执行不在事务上下文中的操作。
示例：
比如，在处理订单时，订单确认操作必须是事务的一部分，因此该操作应该标注为MANDATORY，只有在外部事务存在时才能执行。
NESTED：
- NESTED传播行为允许在当前事务中创建子事务（嵌套事务）。子事务可以独立回滚，而不会影响整个事务。当外部事务提交时，所有的嵌套事务也会提交；如果外部事务回滚，那么嵌套事务也会回滚。该传播行为的优势在于，它支持更加灵活的回滚策略。
示例：
假设有一个数据处理流程，其中有多个步骤。如果其中某一步失败，我们希望仅回滚该步骤，而不是整个事务。在这种情况下，NESTED非常适用，可以将每个步骤封装为一个子事务，独立回滚。

总结

Spring的事务传播行为有七种，每种传播行为适用于不同的业务场景：
– REQUIRED：如果已有事务则加入，否则创建新事务，适用于大多数场景。
– REQUIRES_NEW：总是创建新事务，适用于需要独立事务的操作。
– SUPPORTS：如果有事务则加入，没有则不启动事务，适用于可以选择性加入事务的操作。
– NOT_SUPPORTED：挂起当前事务，适用于不需要事务的操作。
– MANDATORY：必须在现有事务中执行，如果没有事务则抛出异常。
– NEVER：不能在事务中执行，如果有事务则抛出异常。
– NESTED：创建一个嵌套事务，适用于需要支持子事务回滚的场景。

根据具体的业务需求，选择合适的传播行为可以帮助提高事务管理的灵活性和系统的一致性。

参考回答

详细讲解与拓展

总结

发表评论 取消回复

发表评论取消回复