Spring-@Transactional的事务隔离级别

本文详细介绍了Spring中@Transactional注解的事务隔离级别,包括PROPAGATION_REQUIRED、PROPAGATION_SUPPORTS等,并通过案例分析了不同隔离级别在事务处理中的行为差异,特别是PROPAGATION_REQUIRED和PROPAGATION_NESTED的区别。当事务嵌套时,如何影响事务的回滚及提交策略。

//支持当前事务,如果当前没有事务,就新建一个事务。Spring默认事务级别。

int PROPAGATION_REQUIRED = 0;  

//支持当前事务,如果当前没有事务,就以非事务方式执行。

int PROPAGATION_SUPPORTS = 1;  

//支持当前事务,如果当前没有事务,就抛出异常。

int PROPAGATION_MANDATORY = 2;  

//新建事务,如果当前存在事务,把当前事务挂起。执行新事务后,再激活当前事务。

int PROPAGATION_REQUIRES_NEW = 3;  

//以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。

int PROPAGATION_NOT_SUPPORTED = 4;  

//以非事务方式执行,如果当前存在事务,则抛出异常。

int PROPAGATION_NEVER = 5;

//如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则进行与PROPAGATION_REQUIRED类似的操作。

//嵌套时由外部事务决定,子事务是否是commit还是rollback。

//一般在外部事务是使用try{}catch(嵌套事务方法){}进行编码。

int PROPAGATION_NESTED = 6; 

 

案例分析1:

@Service
class A{
    @Autowired
    B b;

    @Transactional(propagation = Propagation.REQUIRED)    
    void call(){
        try{
            b.call();
        } catch(Exception e){
            //doSomething....
            //不抛异常,则A无法提交
        }
        //doSomething....
    }
}

@Service
class B{
    @Transactional(propagation = Propagation.REQUIRED)
    void call(){}
}

A和B共用事务,如果B异常。A未使用try..catch..捕获,则AB一起回滚。

如果B异常。A捕获,但并未抛出。则A最终也无法提交,因为B的事务已经被设置为rollback-only了。

案例分析2:

@Service
class A{
    @Autowired
    B b;

    @Transactional(propagation = Propagation.REQUIRED)    
    void call(){
        try{
            b.call();
        } catch(Exception e){
            throw e; //或者不抛
        }
        //doSomething....
    }
}

@Service
class B{
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    void call(){}
}

执行b.call()时A事务挂起,此时如果B执行异常。被A捕获,如果抛出异常,则AB回滚;如果A捕获未抛异常,则A继续执行不回滚。

执行b.call()时A事务挂起,此时如果B正常执行,而在A中出现异常。则B不回滚,A回滚。

案例分析3:

@Service
class A{
    @Autowired
    B b;

    @Transactional(propagation = Propagation.REQUIRED)    
    void call(){
        try{
            b.call();
        } catch(Exception e){
            throw e; //或者不抛
        }
        //doSomething....
    }
}

@Service
class B{
    @Transactional(propagation = Propagation.NESTED)
    void call(){}
}

执行b.call()时A事务挂起,B新起事务并设置SavePoint。如果B正常执行,A出现异常,则AB一起回滚。

如果B失败异常,此时A如果捕获但未抛出,后续A正常执行的话,A可以提交,而B已经回滚。

如果B失败异常,此时A如果捕获且抛出,则AB一起回滚。

以上案例,我们可以得出第1种和第3种模式的区别,第3种在嵌套模式下,可以在内部异常下执行其它业务且外部正常提交,而第1种不可以这么操作。

### @Transactional 注解中的事务隔离级别 #### 默认隔离级别 当使用 `@Transactional` 注解而未指定隔离级别时,默认采用数据库自身的隔离级别设置。通常情况下,这个默认值为 `ISOLATION_DEFAULT`,意味着会遵循底层数据库所设定的标准隔离等级[^4]。 #### 明确指定隔离级别 为了更精确地控制并发环境下的数据一致性问题,在定义服务层的方法时可以通过 `isolation` 属性来显式指定期望使用的隔离级别: ```java @Service public class ProductService { @Transactional(isolation = Isolation.READ_COMMITTED) public Product getProductById(Long productId) { // 读取产品信息 return productRepository.findById(productId).orElse(null); } } ``` 上述例子中选择了 `READ_COMMITTED` 隔离级别,这种选择能够防止脏读现象的发生,即一个事务不会看到另一个尚未完成的写操作的结果;然而,仍然可能出现不可重复读的问题,也就是同一个查询在同一事务内多次执行可能返回不同的结果集[^3]。 #### 支持的隔离级别选项 Spring 提供了五个标准的隔离级别枚举值用于 `@Transactional` 注解内的配置,分别是: - `DEFAULT`: 使用数据库默认隔离级别- `READ_UNCOMMITTED`: 允许读取还未提交的数据变更,可能导致脏读、幻读等问题。 - `READ_COMMITTED`: 只允许读取已经提交的数据,可避免脏读但无法阻止不可重复读。 - `REPEATABLE_READ`: 确保同一事务内的相同SQL语句得到一致的结果集合,除了能解决前两者外还能处理部分类型的幻读情况。 - `SERIALIZABLE`: 完全串行化访问模式,提供最严格的隔离度,完全杜绝任何形式的不一致读取行为,不过性能开销较大。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值