zoukankan      html  css  js  c++  java
  • Spring中的事务与数据库中的锁关系

    本文只先简单的介绍下Spring中的事务与DB中锁的关系。

    首先总结:Spring事务的实现本质上是使用的DB中的事务,而DB中的事务实现又主要依靠DB中的锁。所以spring事务本质上使用数据库锁,开启spring事务意味着使用数据库锁。

    所以大家一定要厘清DB事务与DB各种锁的原理与概念。后续我也研究一下DB锁,并结合具体的生产环境监控数据来谈谈。

    《以下是转载部分内容。主要是Spring事务的使用方式、隔离级别之类的》

    那么事务的隔离级别与锁有什么关系呢?本人认为事务的隔离级别是通过锁的机制实现的,事务的隔离级别是数据库开发商根据业务逻辑的实际需要定义的一组锁的使用策略。当我们将数据库的隔离级别定义为某一级别后如仍不能满足要求,我们可以自定义 sql 的锁来覆盖事务隔离级别默认的锁机制。
    spring事务实际使用AOP拦截注解方法,然后使用动态代理处理事务方法,捕获处理过程中的异常,spring事务其实是把异常交给spring处理;
    spring事务只有捕获到异常才会终止或回滚,如果你在程序中try/catch后自己处理异常而没有throw,那么事务将不会终止或回滚,失去事务本来的作用;
    spring事务会捕获所有的异常,但只会回滚数据库相关的操作,并且只有在声明了rollbackForClassName="Exception"之类的配置才会回滚;
    spring事务会回滚同一事务中的所有数据库操作,本质上是回滚同一数据库连接上的数据库操作;
     
    spring事务总结:
    spring事务本质上使用数据库锁;
    spring事务只有在方法执行过程中出现异常才会回滚,并且只回滚数据库相关的操作;
     
    对象锁和spring事务的对比:
    对象锁可以保证数据一致性和业务逻辑正确性,但不能保证并发性;
    spring事务不能严格保证数据一致性和业务逻辑正确性,但具有较好的并发性,因为只锁数据库行数据;
     
    建议:
    如果只有insert操作,可以使用事务;
    如果涉及update操作但不涉及其他业务逻辑,可以保守使用事务;
    如果涉及update操作及其他业务逻辑,慎用事务,
    并且数据库查询跟数据库更新之间尽量间隔较短,中间不宜插入太多其他逻辑,减少数据一致性的风险;
    对数据一致性要求不高的情况下可以使用事务结合乐观锁,否则建议用锁;
     
    spring事务为什么不能保证数据一致性和业务逻辑正确性:
    1.如果事务方法抛异常,此时会回滚数据库操作,但已经执行的其他方法不会回滚,因此无法保证业务逻辑正确性;
    2.即使事务方法不抛异常,也不能保证数据一致性(因为事务接口里的数据库操作在整个接口逻辑执行结束后才提交到数据 库,在接口最后提交到数据库的前后很有可能带来数据一致性的问题),从而不能保证业务逻辑正确性;

    Spring 事务的传播属性

    所谓spring事务的传播属性,就是定义在存在多个事务同时存在的时候,spring应该如何处理这些事务的行为。这些属性在TransactionDefinition中定义,具体常量的解释见下表:

    常量名称 常量解释
    PROPAGATION_REQUIRED 支持当前事务,如果当前没有事务,就新建一个事务。这是最常见的选择,也是 Spring 默认的事务的传播。
    PROPAGATION_REQUIRES_NEW 新建事务,如果当前存在事务,把当前事务挂起。新建的事务将和被挂起的事务没有任何关系,是两个独立的事务,外层事务失败回滚之后,不能回滚内层事务执行的结果,内层事务失败抛出异常,外层事务捕获,也可以不处理回滚操作
    PROPAGATION_SUPPORTS 支持当前事务,如果当前没有事务,就以非事务方式执行。
    PROPAGATION_MANDATORY 支持当前事务,如果当前没有事务,就抛出异常。
    PROPAGATION_NOT_SUPPORTED 以非事务方式执行操作,如果当前存在事务,就把当前事务挂起。
    PROPAGATION_NEVER 以非事务方式执行,如果当前存在事务,则抛出异常。
    PROPAGATION_NESTED

    如果一个活动的事务存在,则运行在一个嵌套的事务中。如果没有活动事务,则按REQUIRED属性执行。它使用了一个单独的事务,这个事务拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。

    数据库隔离级别

    隔离级别 隔离级别的值 导致的问题
    Read-Uncommitted 0 导致脏读
    Read-Committed 1 避免脏读,允许不可重复读和幻读
    Repeatable-Read 2 避免脏读,不可重复读,允许幻读
    Serializable 3 串行化读,事务只能一个一个执行,避免了脏读、不可重复读、幻读。执行效率慢,使用时慎重

    Spring中的隔离级别

    常量 解释
    ISOLATION_DEFAULT 这是个 PlatfromTransactionManager 默认的隔离级别,使用数据库默认的事务隔离级别。另外四个与 JDBC 的隔离级别相对应。
    ISOLATION_READ_UNCOMMITTED 这是事务最低的隔离级别,它充许另外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读,不可重复读和幻像读。
    ISOLATION_READ_COMMITTED 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。
    ISOLATION_REPEATABLE_READ 这种事务隔离级别可以防止脏读,不可重复读。但是可能出现幻像读。
    ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。
  • 相关阅读:
    vue3.0提前了解系列一 通过cli快速搭建一个3.0项目
    vscode卡的飞起解决办法-其中之一
    常用正则表达式整理
    jq-outerhtml不能执行新元素内部的js解决方案
    前端面试题(亲身面试经验)
    MAC上Cisco AnyConnect删除不干净,造成无法重新安装的解决办法
    vue需要知道哪些才能算作入门以及熟练
    jquery版本轮播图(es5版本,兼容高)
    webpack4常用片段
    前端速度优化
  • 原文地址:https://www.cnblogs.com/yuerugou54/p/12200821.html
Copyright © 2011-2022 走看看