java中事务的属性_Spring事务属性具体解释

最新推荐文章于 2023-08-22 23:13:40 发布

他们迂回误会

最新推荐文章于 2023-08-22 23:13:40 发布

阅读量235

点赞数

文章标签： java中事务的属性

本文链接：https://blog.csdn.net/weixin_42458217/article/details/114234002

版权

应用程序开发复杂性由Rod

Johnson创建的。框架的主要优势之中的一个就是其分层架构，分层架构同意使用者选择使用哪一个组件，同一时候为 J2EE应用程序开发提供集成的框架。

Spring使用主要的JavaBean来完毕曾经仅仅可能由EJB完毕的事情。然而。Spring的用途不仅限于server端的开发。从简单性、可測试性和松耦合的角度而言，不论什么Java应用都能够从Spring中受益。

Spring声明式事务让我们从复杂的事务处理中得到解脱。使得我们再也不必去处理获得连接、关闭连接、事务提交和回滚等这些操作，再也无需我们在与事务相关的方法中处理大量的try…catch…finally代码。

我们在使用Spring声明式事务时，有一个很重要的概念就是事务属性。事务属性通常由事务的传播行为、事务的隔离级别、事务的超时值、事务仅仅读标志组成。我们在进行事务划分时，须要进行事务定义，也就是配置事务的属性。

Spring在TransactionDefinition接口中定义这些属性，以供PlatfromTransactionManager(github)使用，PlatfromTransactionManager是spring事务管理的核心接口。

TransactionDefinition.java(spring-tx/src/main/java/org/springframework/transaction/TransactionDefinition.java。github)

publicinterfaceTransactionDefinition {

intgetPropagationBehavior();

intgetIsolationLevel();

intgetTimeout();

booleanisReadOnly();

}

1) getPropagationBehavior()：返回事务的传播行为，由是否有一个活动的事务来决定一个事务调用。

2) getTimeout()：它返回事务必须在多少秒内完毕。

3) isReadOnly()：事务是否仅仅读，事务管理器可以依据这个返回值进行优化。确保事务是仅仅读的。

4) getIsolationLevel()：返回事务的隔离级别，事务管理器依据它来控制另外一个事务能够看到本事务内的哪些数据。

1、事务的的隔离级别

在TransactionDefinition接口中，定义了五个不同的事务隔离级别：

1) ISOLATION_DEFAULT (默认隔离级别)

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

2) ISOLATION_READ_UNCOMMITTED (读未提交)

这是事务最低的隔离级别。它充许别外一个事务能够看到这个事务未提交的数据。

这样的隔离级别会产生脏读，不可反复读和幻读。比如:

Mary的原工资为1000,財务人员将Mary的工资改为了8000。但未提交事务

Connection con1 = getConnection();

con.setAutoCommit(false);

update employee set salary = 8000 where empId ="Mary";

与此同一时候，Mary正在读取自己的工资

Connection con2 = getConnection();

select salary from employee where empId ="Mary";

con2.commit();

Mary发现自己的工资变为了8000，欢天喜地！

而財务发现操作有误，而回滚了事务,Mary的工资又变为了1000

//con1

con1.rollback();

像这样,Mary记取的工资数8000是一个脏数据。

3)ISOLATION_READ_COMMITTED(读已提交)

该隔离级别保证一个事务改动的数据提交后才干被另外一个事务读取。另外一个事务不能读取该事务未提交的数据。这样的事务隔离级别能够避免脏读出现，可是可能会出现不可反复读和幻像读。

在事务1中。Mary 读取了自己的工资为1000,操作并没有完毕

con1 = getConnection();

select salary from employee empId ="Mary";

在事务2中，这时財务人员改动了Mary的工资为2000,并提交了事务.

con2 = getConnection();

update employee set salary = 2000;

con2.commit();

在事务1中，Mary 再次读取自己的工资时。工资变为了2000

//con1

select salary from employee empId ="Mary";

在一个事务中前后两次读取的结果并不致。导致了不可反复读。

4)ISOLATION_REPEATABLE_READ

这样的事务隔离级别能够防止脏读，不可反复读。可是可能出现幻像读。它除了保证一个事务不能读取还有一个事务未提交的数据外。还保证了避免以下的情况产生(不可反复读)。

眼下工资为1000的员工有10人。

事务1,读取全部工资为1000的员工。

con1 = getConnection();

Select * from employee where salary =1000;

共读取10条记录

这时还有一个事务向employee表插入了一条员工记录。工资也为1000

con2 = getConnection();

Insert into employee(empId,salary) values("Lili",1000);

con2.commit();

事务1再次读取全部工资为1000的员工

//con1

select * from employee where salary =1000;

共读取到了11条记录，这就产生了幻像读。

5)ISOLATION_SERIALIZABLE

这是花费最高代价可是最可靠的事务隔离级别。

事务被处理为顺序运行。

除了防止脏读，不可反复读外。还避免了幻像读。可是这样也耗费了最大的资源。

2、事务的传播特性

getPropagationBehavior()返回事务的传播行为，由是否有一个活动的事务来决定一个事务调用。

在TransactionDefinition接口中定义了七个事务传播行为。

1)PROPAGATION_REQUIRED

假设存在一个事务，则支持当前事务。假设没有事务则开启一个新的事务。

//事务属性 PROPAGATION_REQUIRED

methodA{

……

methodB();

……

}

//事务属性 PROPAGATION_REQUIRED

methodB{

……

}

使用spring声明式事务，spring使用AOP来支持声明式事务。会依据事务属性。自己主动在方法调用之前决定是否开启一个事务。并在方法运行之后决定事务提交或回滚事务。

单独调用methodB方法

main{

metodB();

}

相当于

Main{

Connection con=null;

rry{

con = getConnection();

con.setAutoCommit(false);

//方法调用

methodB();

//提交事务

con.commit();

}

Catch(RuntimeException ex){

//回滚事务

con.rollback();

}

finally{

//释放资源

closeCon();

}

Spring保证在methodB方法中全部的调用都获得到一个同样的连接。在调用methodB时。没有一个存在的事务。所以获得一个新的连接，开启了一个新的事务。

单独调用MethodA时，在MethodA内又会调用MethodB.

运行效果相当于

main{

Connection con = null;

try{

con = getConnection();

methodA();

con.commit();

}

cathc(RuntimeException ex){

con.rollback();

}

finally{

closeCon();

}

调用MethodA时，环境中没有事务，所以开启一个新的事务.

当在MethodA中调用MethodB时，环境中已经有了一个事务，所以methodB就增加当前事务。

2)PROPAGATION_SUPPORTS

假设存在一个事务，支持当前事务。

假设没有事务，则非事务的运行。可是对于事务同步的事务管理器，PROPAGATION_SUPPORTS与不使用事务有少许不同。

//事务属性 PROPAGATION_REQUIRED

methodA(){

methodB();

}

//事务属性 PROPAGATION_SUPPORTS

methodB(){

……

}

单纯的调用methodB时，methodB方法是非事务的运行的。

当调用methdA时,methodB则增加了methodA的事务中,事务地运行。

3)PROPAGATION_MANDATORY

假设已经存在一个事务，支持当前事务。假设没有一个活动的事务，则抛出异常。

//事务属性 PROPAGATION_REQUIRED

methodA(){

methodB();

}

//事务属性 PROPAGATION_MANDATORY

methodB(){

……

}

当单独调用methodB时，由于当前没有一个活动的事务，则会抛出异常

throw new IllegalTransactionStateException("Transaction propagation 'mandatory' but no existing transaction found");

当调用methodA时，methodB则增加到methodA的事务中，事务地运行。

4) PROPAGATION_REQUIRES_NEW

总是开启一个新的事务。假设一个事务已经存在，则将这个存在的事务挂起。

//事务属性 PROPAGATION_REQUIRED

methodA(){

doSomeThingA();

methodB();

doSomeThingB();

}

//事务属性 PROPAGATION_REQUIRES_NEW

methodB(){

……

}

当单独调用methodB时。相当于把methodb声明为REQUIRED。

开启一个新的事务，事务地运行。

当调用methodA时

main(){

methodA();

}

情况有些大不一样.相当于以下的效果。

main(){

TransactionManager tm = null;

try{

//获得一个JTA事务管理器

tm = getTransactionManager();

tm.begin();//开启一个新的事务

Transaction ts1 = tm.getTransaction();

doSomeThing();

tm.suspend();//挂起当前事务

try{

tm.begin();//又一次开启第二个事务

Transaction ts2 = tm.getTransaction();

methodB();

ts2.commit();//提交第二个事务

}

Catch(RunTimeException ex){

ts2.rollback();//回滚第二个事务

}

finally{

//释放资源

}

//methodB运行完后。复恢第一个事务

tm.resume(ts1);

doSomeThingB();

ts1.commit();//提交第一个事务

}

catch(RunTimeException ex){

ts1.rollback();//回滚第一个事务

}

finally{

//释放资源

}

在这里，我把ts1称为外层事务。ts2称为内层事务。从上面的代码能够看出。ts2与ts1是两个独立的事务。互不相干。Ts2是否成功并不依赖于ts1。

假设methodA方法在调用methodB方法后的doSomeThingB方法失败了，而methodB方法所做的结果依旧被提交。而除了methodB之外的其他代码导致的结果却被回滚了。

使用PROPAGATION_REQUIRES_NEW,须要使用JtaTransactionManager作为事务管理器。

5)PROPAGATION_NOT_SUPPORTED

总是非事务地运行，并挂起不论什么存在的事务。

//事务属性 PROPAGATION_REQUIRED

methodA(){

doSomeThingA();

methodB();

doSomeThingB();

}

//事务属性 PROPAGATION_NOT_SUPPORTED

methodB(){

……

}

当单独调用methodB时。不启用不论什么事务机制，非事务地运行。

当调用methodA时，相当于以下的效果

main(){

TransactionManager tm = null;

try{

//获得一个JTA事务管理器

tm = getTransactionManager();

tm.begin();//开启一个新的事务

Transaction ts1 = tm.getTransaction();

doSomeThing();

tm.suspend();//挂起当前事务

methodB();

//methodB运行完后，复恢第一个事务

tm.resume(ts1);

doSomeThingB();

ts1.commit();//提交第一个事务

}

catch(RunTimeException ex){

ts1.rollback();//回滚第一个事务

}

finally{

//释放资源

}

使用PROPAGATION_NOT_SUPPORTED,也须要使用JtaTransactionManager作为事务管理器。

6)PROPAGATION_NEVER

总是非事务地运行，假设存在一个活动事务，则抛出异常

//事务属性 PROPAGATION_REQUIRED

methodA(){

doSomeThingA();

methodB();

doSomeThingB();

}

//事务属性 PROPAGATION_NEVER

methodB(){

……

}

单独调用methodB，则非事务的运行。

调用methodA则会抛出异常

throw new IllegalTransactionStateException(

"Transaction propagation 'never' but existing transaction found");

7)PROPAGATION_NESTED

假设一个活动的事务存在，则执行在一个嵌套的事务中. 假设没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行

这是一个嵌套事务,使用JDBC 3.0驱动时,只支持DataSourceTransactionManager作为事务管理器。须要JDBC 驱动的java.sql.Savepoint类。

有一些JTA的事务管理器实现可能也提供了相同的功能。

使用PROPAGATION_NESTED，还须要把PlatformTransactionManager的nestedTransactionAllowed属性设为true;

而nestedTransactionAllowed属性值默觉得false;

//事务属性 PROPAGATION_REQUIRED

methodA(){

doSomeThingA();

methodB();

doSomeThingB();

}

//事务属性 PROPAGATION_NESTED

methodB(){

……

}

假设单独调用methodB方法，则按REQUIRED属性运行。

假设调用methodA方法，相当于以下的效果

main(){

Connection con = null;

Savepoint savepoint = null;

try{

con = getConnection();

con.setAutoCommit(false);

doSomeThingA();

savepoint = con2.setSavepoint();

try

methodB();

}catch(RuntimeException ex){

con.rollback(savepoint);

}

finally{

//释放资源

}

doSomeThingB();

con.commit();

}

catch(RuntimeException ex){

con.rollback();

}

finally{

//释放资源

}

当methodB方法调用之前，调用setSavepoint方法。保存当前的状态到savepoint。假设methodB方法调用失败，则恢复到之前保存的状态。可是须要注意的是。这时的事务并没有进行提交，假设兴许的代码(doSomeThingB()方法)调用失败。则回滚包含methodB方法的全部操作。

嵌套事务一个很重要的概念就是内层事务依赖于外层事务。

外层事务失败时，会回滚内层事务所做的动作。而内层事务操作失败并不会引起外层事务的回滚。

PROPAGATION_NESTED 与PROPAGATION_REQUIRES_NEW的差别:它们很类似,都像一个嵌套事务，假设不存在一个活动的事务。都会开启一个新的事务。使用PROPAGATION_REQUIRES_NEW时。内层事务与外层事务就像两个独立的事务一样，一旦内层事务进行了提交后。外层事务不能对其进行回滚。两个事务互不影响。两个事务不是一个真正的嵌套事务。同一时候它须要JTA事务管理器的支持。

使用PROPAGATION_NESTED时。外层事务的回滚能够引起内层事务的回滚。

而内层事务的异常并不会导致外层事务的回滚。它是一个真正的嵌套事务。DataSourceTransactionManager使用savepoint支持PROPAGATION_NESTED时。须要JDBC 3.0以上驱动及1.4以上的JDK版本号支持。其他的JTA TrasactionManager实现可能有不同的支持方式。

PROPAGATION_REQUIRED应该是我们首先的事务传播行为。

它可以满足我们大多数的事务需求。