要先知道什么是java中的事务?
事务: 一般是指要做的或所做的事情.专业术语是这样说的: 就是代码逻辑上的一组操作,这些操作要么全部成功,要么全部失败!举一个现实生活当中的例子:
1张三账上有2000元,李四账号也有2000元。张三要向李四转账1000元,正常来说应该是张三账上-1000元,李四账上+1000元。最后张三账上还剩1000元,李四账上3000元。这样就完成了一个转账的操作.
2.但这组操作不应该出现的情况就是:张三转了1000元之后断电了,或者出现其他的特殊情况。这样就不应该出现张三转出1000元,而李四账上没收到1000元。所以在这种情况下的一组操作我们可以用一个事务来管理。如果这组操作加入了事务管理里面,那么这组操作就必须一起成功,或者一起失败。一起成功就是张三转出1000元,还剩1000元,李四收到1000元账上3000元
![](https://img-blog.csdnimg.cn/img_convert/eee0bba565d8bd9f9fb52c351f73079d.png)
事务还有四个特点
1.事务的原子性( Atomic ) :
一个事务包含多个操作,这些操作要么全部执行,要么全部都不执行.实现事务的原子性,执行回滚操作,在某一个操作失败后,它能够回滚到操作失败之前的状态.
我对原子性的理解: 要么全部成功, 要么全部失败
2. 事务的一致性 ( Consistency ) :
一致性是指事务使得系统从一个一致的状态转换到另一个一致状态。事务的一致性决定了一个系统设计和实现的复杂度。事务可以不同程度的一致性
一致性又分为:
1.强一致性: 读操作可以立即读到提交的更新操作( 操作只要发生改变就会立即更新操作 )
2.弱一致性:提交的更新操作,不一定立即会被读操作读到,此种情况会存在一个不一致窗口,指的是读操作可以读到最新值的一段时间
3. 最终一致性:是弱一致性的特例。事务更新一份数据,最终一致性保证在没有其他事务更新同样的值的话,最终所有的事务都会读到之前事务更新的最新值。如果没有错误发生,不一致窗口的大小依赖于:通信延迟,系统负载等.
4.单调一致性:如果一个进程已经读到一个值,那么后续不会读到更早的值.
5. 会话一致性:保证客户端和服务器交互的会话过程中,读操作可以读到更新操作后的最新值.
3.事务的隔离性( Isolation )
基于 会话 进行 隔离
并发事务之间互相影响的程度,比如,在高并发的情况下,一个事务它会不会读取到另一个未提交的数据呢?在事务并发操作时,可能出现的问题有:
脏读: 事务A修改了一个数据,但未提交,事务B读到了事务A未提交的更新结果,如果事务A提交失败,事务B读到的就是脏数据
不可重复读: 在同一个事务中,对于同一份数据读取到的结果不一致。比如,事务B在事务A提交前读到的结果,和提交后读到的结果可能不同。 不可重复读出现的原因就是事务并发修改记录,要避免这种情况,最简单的方法就是对要修改的记录加锁,这回导致锁竞争加剧,影响性能。另一种方法是通过MVCC可以在无锁的情况下,避免不可重复读
幻读: 在同一个事务中,同一个查询多次返回的结果不一致。事务A新增了一条记录,事务B在事务A提交前后各执行了一次查询操作,发现后一次比前一次多了一条记录。 幻读是由于并发事务增加记录导致的,这个不能像不可重复读通过记录加锁解决,因为对于新增的记录根本无法加锁。需要将事务串行化,才能避免幻读
上面讲到了事务的隔离性,是在于维护多个事务并发操作数据库从而会造成数据不一致的问题,在Mysql中会有几种隔离级别来避免数据不一致问题的发生。
读未提交(Read Uncommited): 该隔离级别是比较低的,从字面意思我们就可以知道,一个事务可以读取到另一个事务没有提交的数据,这样就会造成脏读的现象。
读已提交(Read Commited):这个隔离级别意思是一个事务可以读取到另一个事务已提交的数据,但是这样就会出现一个问题,但一个事务在重复读取一行数据是,不能保证每一次读到的数据是一样的,以为在读取的期间数据可能会被其他的事务进行了修改。但RC可以解决脏读的现象。
可重复度(Repeatable Read): 这是Innodb存储引擎的默认隔离级别,意思的话,当前事务开启后,只会看到事务开启时数据数的数据,期间其他事务对此数据的修改是不会看见的,这样就可以避免脏读和不可重复读的显现,但是如果当前事务结束了,又开启了一个新的事务来读取数据,在开启新的数据之前,有其他事务对此数据脏成了修改,这个时候新开启的数据是可以读到修改后的数据,也就会脏成幻读现象。
串行化:最高级别的隔离级别,意味着事务只能串行执行,不能并发执行。
4. 持久性(Durability)
事务提交后,对系统的影响是永久的.
使用事务时,要求数据引擎必须是InnoDB引擎
JDBC实现事务的方式
1、保证一个业务的所有更新操作中。所使用的连接对象是同一个连接对象
2、将连接对象的提交方式设置为手动提交。
con.setAutoCommit(false);
通过 con.commit()提交事务
如果有异常发送时,可以通过com .rollbac()回滚事务
事务传播行为
事务的传播行为是指的就是但一个事务方法被另外一个事务方法调用时,这个事务方法应该如何进行.
例如:methodA事务方法调用methodB事务方法时,methodB是继续在调用者methodA的事务中运行呢,还是为自己开启一个新事务运行,这就是由methodB的事务传播行为决定的。
![](https://img-blog.csdnimg.cn/img_convert/3f6e16edca5ef824806341414914b764.png)
1、PROPAGATION_REQUIRED
如果存在一个事务,则支持当前事务。如果没有事务则开启一个新的事务。
可以把事务想像成一个胶囊,在这个场景下方法B用的是方法A产生的胶囊(事务)
@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
methodB();
// do something
}
@Transactional(propagation = Propagation.REQUIRED)
public void methodB() {
// do something
}
单独调用methodB方法时,因为当前上下文不存在事务,所以会开启一个新的事务。
调用methodA方法时,因为当前上下文不存在事务,所以会开启一个新的事务。当执行到methodB时,methodB发现当前上下文有事务,因此就加入到当前事务中来
2. PROPAGATION_SUPPORTS
如果存在一个事务,支持当前事务。如果没有事务,则非事务的执行。但是对于事务同步的事务管理器,PROPAGATION_SUPPORTS与不使用事务有少许不同。
举例有两个方法:
@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
methodB();
// do something
}
// 事务属性为SUPPORTS
@Transactional(propagation = Propagation.SUPPORTS)
public void methodB() {
// do something
}
单纯的调用methodB时,methodB方法是非事务的执行的。当调用methdA时,methodB则加入了methodA的事务中,事务正常执行。
3 .PROPAGATION_MANDATORY
如果已经存在一个事务,支持当前事务。如果没有一个活动的事务,则抛出异常。
@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
methodB();
// do something
}
// 事务属性为MANDATORY
@Transactional(propagation = Propagation.MANDATORY)
public void methodB() {
// do something
}
当单独调用methodB时,因为当前没有一个活动的事务,则会抛出异常throw new IllegalTransactionStateException(“Transaction propagation ‘mandatory’ but no existing transaction found”);当调用methodA时,methodB则加入到methodA的事务中,事务地执行。
4. PROPAGATION_MANDATORY
使用PROPAGATION_REQUIRES_NEW,需要使用 JtaTransactionManager作为事务管理器。
它会开启一个新的事务。如果一个事务已经存在,则先将这个存在的事务挂起。
![](https://img-blog.csdnimg.cn/img_convert/ff5659bd4043dce4bac2bbcbd6e34938.png)
@Transactional(propagation = Propagation.REQUIRED)
public void methodA() {
doSomeThingA();
methodB();
doSomeThingB();
// do something else
}
// 事务属性为REQUIRES_NEW
@Transactional(propagation = Propagation.REQUIRES_NEW)
public void methodB() {
// do something
}
当调用
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之外的其它代码导致的结果却被回滚了
5、PROPAGATION_NOT_SUPPORTED
PROPAGATION_NOT_SUPPORTED 总是非事务地执行,并挂起任何存在的事务。使用PROPAGATION_NOT_SUPPORTED,也需要使用JtaTransactionManager作为事务管理器。
![](https://img-blog.csdnimg.cn/img_convert/84aa4f89113b0e8f9e950d569fc1109f.png)
6、PROPAGATION_NEVER
总是非事务地执行,如果存在一个活动事务,则抛出异常。
PROPAGATION_NESTED
![](https://img-blog.csdnimg.cn/img_convert/97ce6940f23326fbc94008f9ce1878a5.png)
如果一个活动的事务存在,则运行在一个嵌套的事务中。 如果没有活动事务, 则按TransactionDefinition.PROPAGATION_REQUIRED 属性执行。
这是一个嵌套事务,使用JDBC 3.0驱动时,仅仅支持DataSourceTransactionManager作为事务管理器。
需要JDBC 驱动的java.sql.Savepoint类。使用PROPAGATION_NESTED,还需要把PlatformTransactionManager的nestedTransactionAllowed属性设为true(属性值默认为false)。
这里关键是嵌套执行。
@Transactional(propagation = Propagation.REQUIRED)
methodA(){
doSomeThingA();
methodB();
doSomeThingB();
}
@Transactional(propagation = Propagation.NEWSTED)
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版本支持。其它的JTATrasactionManager实现可能有不同的支持方式。
PROPAGATION_REQUIRES_NEW 启动一个新的, 不依赖于环境的 “内部” 事务. 这个事务将被完全 commited 或 rolled back 而不依赖于外部事务, 它拥有自己的隔离范围, 自己的锁, 等等. 当内部事务开始执行时, 外部事务将被挂起, 内务事务结束时, 外部事务将继续执行。
另一方面, PROPAGATION_NESTED 开始一个 “嵌套的” 事务, 它是已经存在事务的一个真正的子事务. 潜套事务开始执行时, 它将取得一个 savepoint. 如果这个嵌套事务失败, 我们将回滚到此 savepoint. 潜套事务是外部事务的一部分, 只有外部事务结束后它才会被提交。
由此可见, PROPAGATION_REQUIRES_NEW 和 PROPAGATION_NESTED 的最大区别在于, PROPAGATION_REQUIRES_NEW 完全是一个新的事务, 而 PROPAGATION_NESTED 则是外部事务的子事务, 如果外部事务 commit, 嵌套事务也会被 commit, 这个规则同样适用于 roll back.