「java配置事务隔离级别」java设置事务隔离级别

今天给各位分享java配置事务隔离级别的知识，其中也会对java设置事务隔离级别进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、怎么查看数据库隔离级别
• 2、.spring的事务有几种方式?spring事务的隔离级别和传播行为是什么？
• 3、java ee项目中 spring托管的事务应该怎么设置隔离级别
• 4、程序员新人周一优化一行代码，周三被劝退？
• 5、JAVA连接数据库问题
• 6、解释什么是隔离级别,以db2为例,数据库提供了哪几种隔离级别?每种隔离级别都避

怎么查看数据库隔离级别

修改方法

有两种方法可以对配置了 systemd 的程序进行资源隔离：1. 命令行修改：通过执行 systemctl set-property 命令实现，形式为 systemctl set-property name parameter=value；修改默认即时生效。2. 手工修改文件：直接编辑程序的 systemd unit file 文件，完成之后需手工执行 systemctl daemon-reload 更新配置，并重启服务 systemctl restart name.service。

systemd unit file 里支持的资源隔离配置项，如常见的：

CPUQuota=value

该参数表示服务可以获取的最大 CPU 时间，value 为百分数形式，高于 100% 表示可使用 1 核以上的 CPU。与 cgroup cpu 控制器 cpu.cfs_quota_us 配置项对应。

MemoryLimit=value

该参数表示服务可以使用的最大内存量，value 可以使用 K, M, G, T 等后缀表示值的大小。与 cgroup memory 控制器 memory.limit_in_bytes 配置项对应。

事务的4种隔离级别

READ UNCOMMITTED       未提交读，可以读取未提交的数据。

READ COMMITTED         已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句，InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。                    

Gap locking 仅用于外键约束检查和重复键检查。

REPEATABLE READ        可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。

SERIALIZABLE           序列化在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身间隙)，以及了解整个数据范围的全集组成。

数据范围全集组成

SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；

SQL 语句根据条件扫描到的可能需要加锁的数据范围；

以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）

.spring的事务有几种方式?spring事务的隔离级别和传播行为是什么？

Spring提供了许多内置事务管理器实现，常用的有:

DataSourceTransactionManager（JDBC局部事务）；

JtaTransactionManager（JTA全局事务）；

HibernateTransactionManager（Hibernate事务）。

一、事务的隔离级别：

数据库系统提供了4种事务隔离级别，在这4种隔离级别中，Serializable的隔离级别最高，Read Uncommitted的隔离级别最低；

Read Uncommitted:读未提交数据；（会出现脏读）

Read Committed:读已提交数据；

Repeatable Read:可重复读；

Serializable:串行化。

二、事务的传播属性包括：

Required:业务方法需要在一个事务中运行，如果一个方法运行时已经处在一个事务中，那么加入到该事务，否则为自己创建一个新事务，80%的方法用到该传播属性:

Not-Supported

Requiresnew

Mandatoky

Supports

Never

Nested

Spring是一个开放源代码的设计层面框架，他解决的是业务逻辑层和其他各层的松耦合问题，因此它将面向接口的编程思想贯穿整个系统应用。Spring是于2003 年兴起的一个轻量级的Java 开发框架，由Rod Johnson创建。简单来说，Spring是一个分层的JavaSE/EEfull-stack(一站式) 轻量级开源框架。

java ee项目中 spring托管的事务应该怎么设置隔离级别

可以在XML文件中进行配置，下面的代码是个示意代码

tx:advice id="txAdvice" transaction-manager="txManager"

    tx:attributes

      tx:method name="add*" propagation="REQUIRED" isolation="READ_COMMITTED"/增加记录的方法

      tx:method name="get*" propagation="REQUIRED" isolation="READ_COMMITTED"/获取记录的方法

      tx:method name="delete*" propagation="REQUIRED" isolation="READ_COMMITTED"/删除的方法

      tx:method name="update*" propagation="REQUIRED" isolation="SERIALIZABLE"/更改记录的方法

    /tx:attributes

  /tx:advice

下面扩展将一下spring里面事务的传播属性和事务隔离级别。

一、Propagation （事务的传播属性）

Propagationkey属性确定代理应该给哪个方法增加事务行为。这样的属性最重要的部份是传播行为。有以下选项可供使用：PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。

PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。

PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。

PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。

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

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

1： PROPAGATION_REQUIRED

加入当前正要执行的事务不在另外一个事务里，那么就起一个新的事务

比如说，ServiceB.methodB的事务级别定义为PROPAGATION_REQUIRED, 那么由于执行ServiceA.methodA的时候，

ServiceA.methodA已经起了事务，这时调用ServiceB.methodB，ServiceB.methodB看到自己已经运行在ServiceA.methodA

的事务内部，就不再起新的事务。而假如ServiceA.methodA运行的时候发现自己没有在事务中，他就会为自己分配一个事务。

这样，在ServiceA.methodA或者在ServiceB.methodB内的任何地方出现异常，事务都会被回滚。即使ServiceB.methodB的事务已经被

提交，但是ServiceA.methodA在接下来fail要回滚，ServiceB.methodB也要回滚

2： PROPAGATION_SUPPORTS

如果当前在事务中，即以事务的形式运行，如果当前不再一个事务中，那么就以非事务的形式运行

3： PROPAGATION_MANDATORY

必须在一个事务中运行。也就是说，他只能被一个父事务调用。否则，他就要抛出异常

4： PROPAGATION_REQUIRES_NEW

这个就比较绕口了。 比如我们设计ServiceA.methodA的事务级别为PROPAGATION_REQUIRED，ServiceB.methodB的事务级别为PROPAGATION_REQUIRES_NEW，

那么当执行到ServiceB.methodB的时候，ServiceA.methodA所在的事务就会挂起，ServiceB.methodB会起一个新的事务，等待ServiceB.methodB的事务完成以后，

他才继续执行。他与PROPAGATION_REQUIRED 的事务区别在于事务的回滚程度了。因为ServiceB.methodB是新起一个事务，那么就是存在

两个不同的事务。如果ServiceB.methodB已经提交，那么ServiceA.methodA失败回滚，ServiceB.methodB是不会回滚的。如果ServiceB.methodB失败回滚，

如果他抛出的异常被ServiceA.methodA捕获，ServiceA.methodA事务仍然可能提交。

5： PROPAGATION_NOT_SUPPORTED

当前不支持事务。比如ServiceA.methodA的事务级别是PROPAGATION_REQUIRED ，而ServiceB.methodB的事务级别是PROPAGATION_NOT_SUPPORTED ，

那么当执行到ServiceB.methodB时，ServiceA.methodA的事务挂起，而他以非事务的状态运行完，再继续ServiceA.methodA的事务。

6： PROPAGATION_NEVER

不能在事务中运行。假设ServiceA.methodA的事务级别是PROPAGATION_REQUIRED， 而ServiceB.methodB的事务级别是PROPAGATION_NEVER ，

那么ServiceB.methodB就要抛出异常了。

7： PROPAGATION_NESTED

理解Nested的关键是savepoint。他与PROPAGATION_REQUIRES_NEW的区别是，PROPAGATION_REQUIRES_NEW另起一个事务，将会与他的父事务相互独立，

而Nested的事务和他的父事务是相依的，他的提交是要等和他的父事务一块提交的。也就是说，如果父事务最后回滚，他也要回滚的。

而Nested事务的好处是他有一个savepoint。

*****************************************

ServiceA {

/**

* 事务属性配置为 PROPAGATION_REQUIRED

*/

void methodA() {

try {

//savepoint

ServiceB.methodB(); //PROPAGATION_NESTED 级别

} catch (SomeException) {

// 执行其他业务, 如 ServiceC.methodC();

}

}

}

********************************************

也就是说ServiceB.methodB失败回滚，那么ServiceA.methodA也会回滚到savepoint点上，ServiceA.methodA可以选择另外一个分支，比如

ServiceC.methodC，继续执行，来尝试完成自己的事务。

但是这个事务并没有在EJB标准中定义。

二、Spring事务的隔离级别

 1. ISOLATION_DEFAULT： 这是一个PlatfromTransactionManager默认的隔离级别，使用数据库默认的事务隔离级别。另外四个与JDBC的隔离级别相对应

 2. ISOLATION_READ_UNCOMMITTED： 这是事务最低的隔离级别，它充许令外一个事务可以看到这个事务未提交的数据。这种隔离级别会产生脏读，不可重复读和幻像读。

 3. ISOLATION_READ_COMMITTED： 保证一个事务修改的数据提交后才能被另外一个事务读取。另外一个事务不能读取该事务未提交的数据

 4. ISOLATION_REPEATABLE_READ： 这种事务隔离级别可以防止脏读，不可重复读。但是可能出现幻像读。它除了保证一个事务不能读取另一个事务未提交的数据外，还保证了避免下面的情况产生(不可重复读)。

 5. ISOLATION_SERIALIZABLE 这是花费最高代价但是最可靠的事务隔离级别。事务被处理为顺序执行。除了防止脏读，不可重复读外，还避免了幻像读。

什么是脏数据，脏读，不可重复读，幻觉读？

脏读: 指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。因为这个数据是还没有提交的数据， 那么另外一个事务读到的这个数据是脏数据，依据脏数据所做的操作可能是不正确的。

不可重复读: 指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

幻觉读: 指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

程序员新人周一优化一行代码，周三被劝退？

这周一，公司新来了一个同事，面试的时候表现得非常不错，各种问题对答如流，老板和我都倍感欣慰。

这么优秀的人，绝不能让他浪费一分一秒，于是很快，我就发他了需求文档、源码，让他先在本地熟悉一下业务和开发流程。

结果没想到，周三大家一块 review 代码的时候就发现了问题，新来的同事直接把原来 @Transactional 优化成了这个鬼样子：

就因为这一行代码，老板（当年也是一线互联网大厂的好手）当场就发飙了，马上就要劝退这位新同事，我就赶紧打圆场，毕竟自己面试的人，不看僧面看佛面，是吧？于是老板答应我说再试用一个月看看。

会议结束后，我就赶紧让新同事复习了一遍事务，以下是他自己做的总结，还是非常详细的，分享出来给大家一点点参考和启发。相信大家看完后就明白为什么不能这样优化 @Transactional 注解了，纯属画蛇添足和乱用。

事务在逻辑上是一组操作， 要么执行，要不都不执行 。主要是针对数据库而言的，比如说 MySQL。

只要记住这一点，理解事务就很容易了。在 Java 中，我们通常要在业务里面处理多个事件，比如说编程喵有一个保存文章的方法，它除了要保存文章本身之外，还要保存文章对应的标签，标签和文章不在同一个表里，但会通过在文章表里（posts）保存标签主键（tag_id）来关联标签表（tags）：

那么此时就需要开启事务，保证文章表和标签表中的数据保持同步，要么都执行，要么都不执行。

否则就有可能造成，文章保存成功了，但标签保存失败了，或者文章保存失败了，标签保存成功了——这些场景都不符合我们的预期。

为了保证事务是正确可靠的，在数据库进行写入或者更新操作时，就必须得表现出 ACID 的 4 个重要特性：

其中，事务隔离又分为 4 种不同的级别，包括：

需要格外注意的是： 事务能否生效，取决于数据库引擎是否支持事务，MySQL 的 InnoDB 引擎是支持事务的，但 MyISAM 就不支持 。

1）编程式事务

编程式事务是指将事务管理代码嵌入嵌入到业务代码中，来控制事务的提交和回滚。

你比如说，使用 TransactionTemplate 来管理事务：

再比如说，使用 TransactionManager 来管理事务：

就编程式事务管理而言，Spring 更推荐使用 TransactionTemplate。

在编程式事务中，必须在每个业务操作中包含额外的事务管理代码，就导致代码看起来非常的臃肿，但对理解 Spring 的事务管理模型非常有帮助。

当然了，要想实现事务管理和业务代码的抽离，就必须得用到 Spring 当中最关键最核心的技术之一，AOP，其本质是对方法前后进行拦截，然后在目标方法开始之前创建或者加入一个事务，执行完目标方法之后根据执行的情况提交或者回滚。

Spring 将事务管理的核心抽象为一个事务管理器（TransactionManager），它的源码只有一个简单的接口定义，属于一个标记接口：

通过 PlatformTransactionManager 这个接口，Spring 为各个平台如 JDBC(DataSourceTransactionManager)、Hibernate(HibernateTransactionManager)、JPA(JpaTransactionManager)等都提供了对应的事务管理器，但是具体的实现就是各个平台自己的事情了。

参数 TransactionDefinition 和 @Transactional 注解是对应的，比如说 @Transactional 注解中定义的事务传播行为、隔离级别、事务超时时间、事务是否只读等属性，在 TransactionDefinition 都可以找得到。

返回类型 TransactionStatus 主要用来存储当前事务的一些状态和数据，比如说事务资源（connection）、回滚状态等。

TransactionDefinition.java：

Transactional.java

说到这，我们来详细地说明一下 Spring 事务的传播行为、事务的隔离级别、事务的超时时间、事务的只读属性，以及事务的回滚规则。

当事务方法被另外一个事务方法调用时，必须指定事务应该如何传播 ，例如，方法可能继续在当前事务中执行，也可以开启一个新的事务，在自己的事务中执行。

TransactionDefinition 一共定义了 7 种事务传播行为：

01、 PROPAGATION_REQUIRED

这也是 @Transactional 默认的事务传播行为，指的是如果当前存在事务，则加入该事务；如果当前没有事务，则创建一个新的事务。更确切地意思是：

这个传播行为也最好理解，aMethod 调用了 bMethod，只要其中一个方法回滚，整个事务均回滚。

02、 PROPAGATION_REQUIRES_NEW

创建一个新的事务，如果当前存在事务，则把当前事务挂起。也就是说不管外部方法是否开启事务，Propagation.REQUIRES_NEW 修饰的内部方法都会开启自己的事务，且开启的事务与外部的事务相互独立，互不干扰。

如果 aMethod()发生异常回滚，bMethod()不会跟着回滚，因为 bMethod()开启了独立的事务。但是，如果 bMethod()抛出了未被捕获的异常并且这个异常满足事务回滚规则的话,aMethod()同样也会回滚。

03、 PROPAGATION_NESTED

如果当前存在事务，就在当前事务内执行；否则，就执行与 PROPAGATION_REQUIRED 类似的操作。

04、 PROPAGATION_MANDATORY

如果当前存在事务，则加入该事务；如果当前没有事务，则抛出异常。

05、 PROPAGATION_SUPPORTS

如果当前存在事务，则加入该事务；如果当前没有事务，则以非事务的方式继续运行。

06、 PROPAGATION_NOT_SUPPORTED

以非事务方式运行，如果当前存在事务，则把当前事务挂起。

07、 PROPAGATION_NEVER

以非事务方式运行，如果当前存在事务，则抛出异常。

3、4、5、6、7 这 5 种事务传播方式不常用，了解即可。

前面我们已经了解了数据库的事务隔离级别，再来理解 Spring 的事务隔离级别就容易多了。

TransactionDefinition 中一共定义了 5 种事务隔离级别：

通常情况下，我们采用默认的隔离级别 ISOLATION_DEFAULT 就可以了，也就是交给数据库来决定，可以通过 SELECT @@transaction_isolation; 命令来查看 MySql 的默认隔离级别，结果为 REPEATABLE-READ，也就是可重复读。

事务超时，也就是指一个事务所允许执行的最长时间，如果在超时时间内还没有完成的话，就自动回滚。

假如事务的执行时间格外的长，由于事务涉及到对数据库的锁定，就会导致长时间运行的事务占用数据库资源。

如果一个事务只是对数据库执行读操作，那么该数据库就可以利用事务的只读属性，采取优化措施，适用于多条数据库查询操作中。

这是因为 MySql（innodb）默认对每一个连接都启用了 autocommit 模式，在该模式下，每一个发送到 MySql 服务器的 SQL 语句都会在一个单独的事务中进行处理，执行结束后会自动提交事务。

那如果我们给方法加上了 @Transactional 注解，那这个方法中所有的 SQL 都会放在一个事务里。否则，每条 SQL 都会单独开启一个事务，中间被其他事务修改了数据，都会实时读取到。

有些情况下，当一次执行多条查询语句时，需要保证数据一致性时，就需要启用事务支持。否则上一条 SQL 查询后，被其他用户改变了数据，那么下一个 SQL 查询可能就会出现不一致的状态。

默认情况下，事务只在出现运行时异常（Runtime Exception）时回滚，以及 Error，出现检查异常（checked exception，需要主动捕获处理或者向上抛出）时不回滚。

如果你想要回滚特定的异常类型的话，可以这样设置：

以前，我们需要通过 XML 配置 Spring 来托管事务，有了 Spring Boot 之后，一切就变得更加简单了，只需要在业务层添加事务注解（ @Transactional ）就可以快速开启事务。

也就是说，我们只需要把焦点放在 @Transactional 注解上就可以了。

虽然 @Transactional 注解源码中定义了很多属性，但大多数时候，我都是采用默认配置，当然了，如果需要自定义的话，前面也都说明过了。

1）要在 public 方法上使用，在AbstractFallbackTransactionAttributeSource类的computeTransactionAttribute方法中有个判断，如果目标方法不是public，则TransactionAttribute返回null，即不支持事务。

2）避免同一个类中调用 @Transactional 注解的方法，这样会导致事务失效。

在测试之前，我们先把 Spring Boot 默认的日志级别 info 调整为 debug，在 application.yml 文件中 修改：

然后，来看修改之前查到的数据：

开搞。在控制器中添加一个 update 接口，准备修改数据，打算把沉默王二的狗腿子修改为沉默王二的狗腿：

在 Service 中为方法加上 @Transactional 注解并抛出运行时异常：

按照我们的预期，当执行 save 保存数据后，因为出现了异常，所以事务要回滚。所以数据不会被修改。

在浏览器中输入 进行测试，注意查看日志，可以确认事务起效了。

当我们把事务去掉，同样抛出异常：

再次执行，发现虽然程序报错了，但数据却被更新了。

这也间接地证明，我们的 @Transactional 事务起效了。

看到这，是不是就明白为什么新同事的优化纯属画蛇添足/卵用了吧？

JAVA连接数据库问题

JDBC 事务隔离级别

作用：

1：保证数据的正确性，保证如下特征： a:原子性：如果因故障中断，则所有结果都撤消 b:一致性：事务处理的结果保留不变的特性 c:孤立性：中间状态对其他事务是不可见的 d:持久性：完成事务的结果是持久的

事务终止的两种方式：1提交，一个事务使其结果永久不变，2回滚，撤消所有更改回到原来状态。

2：解决数据同时读取的问题： 3个问题：

a:脏读取：一个事务读取了另外一个并行事务未提交的数据

b:不可重复读取：一个事务再次读取之前的 数据时得到的数据不一致，被另外一个事务修改 c:虚读：一个事务重新执行一个查询，返回的记录包含了其他事务提交的新记录

解决办法：

设定事务的隔离级别：con.setTransactionIsolation(Connection.isolationLevel);

四种隔离级别：

con.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);//最底级别：只保证不会读到非法数据，上述3个问题有可能发生

con.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED); //默认级别：可以防止脏读

con.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);//可以防止脏读和不可重复读取

con.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE); //最高级别：防止上述3种情况，事务串行执行

解释什么是隔离级别,以db2为例,数据库提供了哪几种隔离级别?每种隔离级别都避

1.查看当前会话隔离级别

select @@tx_isolation;

2.查看系统当前隔离级别

select @@global.tx_isolation;

3.设置当前会话隔离级别

set session transaction isolatin level repeatable read;

4.设置系统当前隔离级别

set global transaction isolation level repeatable read;

5.命令行，开始事务时

set autocommit=off 或者 start transaction

关于隔离级别的理解

1.read uncommitted

可以看到未提交的数据（脏读），举个例子：别人说的话你都相信了，但是可能他只是说说，并不实际做。

2.read committed

读取提交的数据。但是，可能多次读取的数据结果不一致（不可重复读，幻读）。用读写的观点就是：读取的行数据，可以写。

3.repeatable read(MySQL默认隔离级别)

可以重复读取，但有幻读。读写观点：读取的数据行不可写，但是可以往表中新增数据。在MySQL中，其他事务新增的数据，看不到，不会产生幻读。采用多版本并发控制（MVCC）机制解决幻读问题。

4.serializable

可读，不可写。像java中的锁，写数据必须等待另一个事务结束。

java配置事务隔离级别的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java设置事务隔离级别、java配置事务隔离级别的信息别忘了在本站进行查找喔。