spring5 源码深度解析----- 事务的回滚和提交（100%理解事务）
程序员文章站
2022-05-31 19:14:33
上一篇文章讲解了获取事务，并且通过获取的connection设置只读、隔离级别等，这篇文章讲解剩下的事务的回滚和提交 回滚处理 之前已经完成了目标方法运行前的事务准备工作，而这些准备工作最大的目的无非是对于程序没有按照我们期待的那样进行，也就是出现特定的错误，那么，当出现错误的时候，Spring是怎 ......
上一篇文章讲解了获取事务，并且通过获取的connection设置只读、隔离级别等，这篇文章讲解剩下的事务的回滚和提交
回滚处理
之前已经完成了目标方法运行前的事务准备工作，而这些准备工作最大的目的无非是对于程序没有按照我们期待的那样进行，也就是出现特定的错误，那么，当出现错误的时候，spring是怎么对数据进行恢复的呢？
1 protected void completetransactionafterthrowing(@nullable transactioninfo txinfo, throwable ex) {
2 // 当抛出异常时首先判断当前是否存在事务，这是基础依据
3 if (txinfo != null && txinfo.gettransactionstatus() != null) {
4 if (logger.istraceenabled()) {
5 logger.trace("completing transaction for [" + txinfo.getjoinpointidentification() +
6 "] after exception: " + ex);
7 }
8 // 这里判断是否回滚默认的依据是抛出的异常是否是runtimeexception或者是error的类型
9 if (txinfo.transactionattribute != null && txinfo.transactionattribute.rollbackon(ex)) {
10 try {
11 txinfo.gettransactionmanager().rollback(txinfo.gettransactionstatus());
12 }
13 catch (transactionsystemexception ex2) {
14 logger.error("application exception overridden by rollback exception", ex);
15 ex2.initapplicationexception(ex);
16 throw ex2;
17 }
18 catch (runtimeexception | error ex2) {
19 logger.error("application exception overridden by rollback exception", ex);
20 throw ex2;
21 }
22 }
23 else {
24 // we don't roll back on this exception.
25 // will still roll back if transactionstatus.isrollbackonly() is true.
26 // 如果不满足回滚条件即使抛出异常也同样会提交
27 try {
28 txinfo.gettransactionmanager().commit(txinfo.gettransactionstatus());
29 }
30 catch (transactionsystemexception ex2) {
31 logger.error("application exception overridden by commit exception", ex);
32 ex2.initapplicationexception(ex);
33 throw ex2;
34 }
35 catch (runtimeexception | error ex2) {
36 logger.error("application exception overridden by commit exception", ex);
37 throw ex2;
38 }
39 }
40 }
41 }
在对目标方法的执行过程中，一旦出现throwable就会被引导至此方法处理，但是并不代表所有的throwable都会被回滚处理，比如我们最常用的exception，默认是不会被处理的。 默认情况下，即使出现异常，数据也会被正常提交，而这个关键的地方就是在txlnfo.transactionattribute.rollbackon(ex)这个函数。
回滚条件
@override
public boolean rollbackon(throwable ex) {
return (ex instanceof runtimeexception || ex instanceof error);
}
默认情况下spring中的亊务异常处理机制只对runtimeexception和error两种情况感兴趣，我们可以利用注解方式来改变，例如：
@transactional(propagation = propagation.required, rollbackfor = exception.class)
回滚处理
当然，一旦符合回滚条件，那么spring就会将程序引导至回滚处理函数中。
1 private void processrollback(defaulttransactionstatus status, boolean unexpected) {
2 try {
3 boolean unexpectedrollback = unexpected;
4
5 try {
6 triggerbeforecompletion(status);
7 // 如果status有savepoint，说明此事务是nestd，且为子事务，只回滚到savepoint
8 if (status.hassavepoint()) {
9 if (status.isdebug()) {
10 logger.debug("rolling back transaction to savepoint");
11 }
12 //回滚到保存点
13 status.rollbacktoheldsavepoint();
14 }
15 // 如果此时的status显示是新的事务才进行回滚
16 else if (status.isnewtransaction()) {
17 if (status.isdebug()) {
18 logger.debug("initiating transaction rollback");
19 }
20 //如果此时是子事务，我们想想哪些类型的事务会进入到这里？
21 //回顾上一篇文章中已存在事务的处理，not_supported创建的status是preparetransactionstatus(definition, null, false...)，说明是旧事物，并且事务为null，不会进入
22 //requires_new会创建一个新的子事务，status是newtransactionstatus(definition, transaction, true...)说明是新事务，将会进入到这个分支
23 //propagation_nested创建的status是preparetransactionstatus(definition, transaction, false...)是旧事物，使用的是外层的事务，不会进入
24 //propagation_supports 或 propagation_required或propagation_mandatory存在事务加入事务即可，标记为旧事务,preparetransactionstatus(definition, transaction, false..)
25 //说明当子事务，只有requires_new会进入到这里进行回滚
26 dorollback(status);
27 }
28 else {
29 // participating in larger transaction
30 // 如果status中有事务，进入下面
31 // 根据上面分析，propagation_supports 或 propagation_required或propagation_mandatory创建的status是preparetransactionstatus(definition, transaction, false..)
32 // 如果此事务时子事务，表示存在事务，并且事务为旧事物，将进入到这里
33 if (status.hastransaction()) {
34 if (status.islocalrollbackonly() || isglobalrollbackonparticipationfailure()) {
35 if (status.isdebug()) {
36 logger.debug("participating transaction failed - marking existing transaction as rollback-only");
37 }
38 // 对status中的transaction作一个回滚了的标记，并不会立即回滚
39 dosetrollbackonly(status);
40 }
41 else {
42 if (status.isdebug()) {
43 logger.debug("participating transaction failed - letting transaction originator decide on rollback");
44 }
45 }
46 }
47 else {
48 logger.debug("should roll back transaction but cannot - no transaction available");
49 }
50 // unexpected rollback only matters here if we're asked to fail early
51 if (!isfailearlyonglobalrollbackonly()) {
52 unexpectedrollback = false;
53 }
54 }
55 }
56 catch (runtimeexception | error ex) {
57 triggeraftercompletion(status, transactionsynchronization.status_unknown);
58 throw ex;
59 }
60
61 triggeraftercompletion(status, transactionsynchronization.status_rolled_back);
62
63 }
64 finally {
65 // 清空记录的资源并将挂起的资源恢复
66 // 子事务结束了，之前挂起的事务就要恢复了
67 cleanupaftercompletion(status);
68 }
69 }
我i们先来看看第13行，回滚到保存点的代码，根据保存点回滚的实现方式其实是根据底层的数据库连接进行的。回滚到保存点之后，也要释放掉当前的保存点
public void rollbacktoheldsavepoint() throws transactionexception {
object savepoint = getsavepoint();
if (savepoint == null) {
throw new transactionusageexception(
"cannot roll back to savepoint - no savepoint associated with current transaction");
}
getsavepointmanager().rollbacktosavepoint(savepoint);
getsavepointmanager().releasesavepoint(savepoint);
setsavepoint(null);
}
这里使用的是jdbc的方式进行数据库连接，那么getsavepointmanager()函数返回的是jdbctransactionobjectsupport，也就是说上面函数会调用jdbctransactionobjectsupport 中的 rollbacktosavepoint 方法。
@override
public void rollbacktosavepoint(object savepoint) throws transactionexception {
connectionholder conholder = getconnectionholderforsavepoint();
try {
conholder.getconnection().rollback((savepoint) savepoint);
conholder.resetrollbackonly();
}
catch (throwable ex) {
throw new transactionsystemexception("could not roll back to jdbc savepoint", ex);
}
}
当之前已经保存的事务信息中的事务为新事物，那么直接回滚。常用于单独事务的处理。对于没有保存点的回滚，spring同样是使用底层数据库连接提供的api来操作的。由于我们使用的是datasourcetransactionmanager，那么dorollback函数会使用此类中的实现：
@override
protected void dorollback(defaulttransactionstatus status) {
datasourcetransactionobject txobject = (datasourcetransactionobject) status.gettransaction();
connection con = txobject.getconnectionholder().getconnection();
if (status.isdebug()) {
logger.debug("rolling back jdbc transaction on connection [" + con + "]");
}
try {
con.rollback();
}
catch (sqlexception ex) {
throw new transactionsystemexception("could not roll back jdbc transaction", ex);
}
}
当前事务信息中表明是存在事务的，又不属于以上两种情况，只做回滚标识，等到提交的时候再判断是否有回滚标识，下面回滚的时候再介绍，子事务中状态为propagation_supports 或 propagation_required或propagation_mandatory回滚的时候将会标记为回滚标识，我们来看看是怎么标记的
@override
protected void dosetrollbackonly(defaulttransactionstatus status) {
// 将status中的transaction取出
datasourcetransactionobject txobject = (datasourcetransactionobject) status.gettransaction();
if (status.isdebug()) {
logger.debug("setting jdbc transaction [" + txobject.getconnectionholder().getconnection() +
"] rollback-only");
}
// transaction执行标记回滚
txobject.setrollbackonly();
}
public void setrollbackonly() {
// 这里将transaction里面的connholder标记回滚
getconnectionholder().setrollbackonly();
}
public void setrollbackonly() {
// 将holder中的这个属性设置成true
this.rollbackonly = true;
}
我们看到将status中的transaction中的 connectionholder的属性rollbackonly标记为true,这里我们先不多考虑，等到下面提交的时候再介绍
我们简单的做个小结
- status.hassavepoint()如果status中有savepoint，只回滚到savepoint！
- status.isnewtransaction()如果status是一个新事务，才会真正去回滚！
- status.hastransaction()如果status有事务，将会对staus中的事务标记！
事务提交
在事务的执行并没有出现任何的异常，也就意味着事务可以走正常事务提交的流程了。这里回到流程中去，看看committransactionafterreturning(txinfo)方法做了什么：
protected void committransactionafterreturning(@nullable transactioninfo txinfo) {
if (txinfo != null && txinfo.gettransactionstatus() != null) {
if (logger.istraceenabled()) {
logger.trace("completing transaction for [" + txinfo.getjoinpointidentification() + "]");
}
txinfo.gettransactionmanager().commit(txinfo.gettransactionstatus());
}
}
在真正的数据提交之前，还需要做个判断。不知道大家还有没有印象，在我们分析事务异常处理规则的时候，当某个事务既没有保存点又不是新事物，spring对它的处理方式只是设置一个回滚标识。这个回滚标识在这里就会派上用场了，如果子事务状态是
propagation_supports 或 propagation_required或propagation_mandatory，将会在外层事务中运行，回滚的时候，并不执行回滚，只是标记一下回滚状态，当外层事务提交的时候，会先判断connectionholder中的回滚状态，如果已经标记为回滚，则不会提交，而是外层事务进行回滚
1 @override
2 public final void commit(transactionstatus status) throws transactionexception {
3 if (status.iscompleted()) {
4 throw new illegaltransactionstateexception(
5 "transaction is already completed - do not call commit or rollback more than once per transaction");
6 }
7
8 defaulttransactionstatus defstatus = (defaulttransactionstatus) status;
9 // 如果在事务链中已经被标记回滚，那么不会尝试提交事务，直接回滚
10 if (defstatus.islocalrollbackonly()) {
11 if (defstatus.isdebug()) {
12 logger.debug("transactional code has requested rollback");
13 }
14 processrollback(defstatus, false);
15 return;
16 }
17
18 if (!shouldcommitonglobalrollbackonly() && defstatus.isglobalrollbackonly()) {
19 if (defstatus.isdebug()) {
20 logger.debug("global transaction is marked as rollback-only but transactional code requested commit");
21 }
22 // 这里会进行回滚，并且抛出一个异常
23 processrollback(defstatus, true);
24 return;
25 }
26
27 // 如果没有被标记回滚之类的，这里才真正判断是否提交
28 processcommit(defstatus);
29 }
而当事务执行一切都正常的时候，便可以真正地进入提交流程了。
private void processcommit(defaulttransactionstatus status) throws transactionexception {
try {
boolean beforecompletioninvoked = false;
try {
boolean unexpectedrollback = false;
prepareforcommit(status);
triggerbeforecommit(status);
triggerbeforecompletion(status);
beforecompletioninvoked = true;
// 判断是否有savepoint
if (status.hassavepoint()) {
if (status.isdebug()) {
logger.debug("releasing transaction savepoint");
}
unexpectedrollback = status.isglobalrollbackonly();
// 不提交，仅仅是释放savepoint
status.releaseheldsavepoint();
}
// 判断是否是新事务
else if (status.isnewtransaction()) {
if (status.isdebug()) {
logger.debug("initiating transaction commit");
}
unexpectedrollback = status.isglobalrollbackonly();
// 这里才真正去提交！
docommit(status);
}
else if (isfailearlyonglobalrollbackonly()) {
unexpectedrollback = status.isglobalrollbackonly();
}
// throw unexpectedrollbackexception if we have a global rollback-only
// marker but still didn't get a corresponding exception from commit.
if (unexpectedrollback) {
throw new unexpectedrollbackexception(
"transaction silently rolled back because it has been marked as rollback-only");
}
}
catch (unexpectedrollbackexception ex) {
// 略...
}
// trigger aftercommit callbacks, with an exception thrown there
// propagated to callers but the transaction still considered as committed.
try {
triggeraftercommit(status);
}
finally {
triggeraftercompletion(status, transactionsynchronization.status_committed);
}
}
finally {
// 清空记录的资源并将挂起的资源恢复
cleanupaftercompletion(status);
}
}
- status.hassavepoint()如果status有savepoint，说明此时的事务是嵌套事务nested，这个事务外面还有事务，这里不提交，只是释放保存点。这里也可以看出来nested的传播行为了。
- status.isnewtransaction()如果是新的事务，才会提交！！，这里如果是子事务，只有propagation_nested状态才会走到这里提交，也说明了此状态子事务提交和外层事务是隔离的
- 如果是子事务，propagation_supports 或 propagation_required或propagation_mandatory这几种状态是旧事物，提交的时候将什么都不做，因为他们是运行在外层事务当中，如果子事务没有回滚，将由外层事务一次性提交
如果程序流通过了事务的层层把关，最后顺利地进入了提交流程，那么同样，spring会将事务提交的操作引导至底层数据库连接的api，进行事务提交。
@override
protected void docommit(defaulttransactionstatus status) {
datasourcetransactionobject txobject = (datasourcetransactionobject) status.gettransaction();
connection con = txobject.getconnectionholder().getconnection();
if (status.isdebug()) {
logger.debug("committing jdbc transaction on connection [" + con + "]");
}
try {
con.commit();
}
catch (sqlexception ex) {
throw new transactionsystemexception("could not commit jdbc transaction", ex);
}
}
从回滚和提交的逻辑看，只有status是新事务，才会进行提交或回滚，需要读者记好这个状态–>是否是新事务。
清理工作
而无论是在异常还是没有异常的流程中，最后的finally块中都会执行一个方法cleanupaftercompletion(status)
private void cleanupaftercompletion(defaulttransactionstatus status) {
// 设置完成状态
status.setcompleted();
if (status.isnewsynchronization()) {
transactionsynchronizationmanager.clear();
}
if (status.isnewtransaction()) {
docleanupaftercompletion(status.gettransaction());
}
if (status.getsuspendedresources() != null) {
if (status.isdebug()) {
logger.debug("resuming suspended transaction after completion of inner transaction");
}
object transaction = (status.hastransaction() ? status.gettransaction() : null);
// 结束之前事务的挂起状态
resume(transaction, (suspendedresourcesholder) status.getsuspendedresources());
}
}
如果是新事务需要做些清除资源的工作？
@override
protected void docleanupaftercompletion(object transaction) {
datasourcetransactionobject txobject = (datasourcetransactionobject) transaction;
// remove the connection holder from the thread, if exposed.
if (txobject.isnewconnectionholder()) {
// 将数据库连接从当前线程中解除绑定，解绑过程我们在挂起的过程中已经分析过
transactionsynchronizationmanager.unbindresource(obtaindatasource());
}
// reset connection.
// 释放连接，当前事务完成，则需要将连接释放，如果有线程池，则重置数据库连接，放回线程池
connection con = txobject.getconnectionholder().getconnection();
try {
if (txobject.ismustrestoreautocommit()) {
// 恢复数据库连接的自动提交属性
con.setautocommit(true);
}
// 重置数据库连接
datasourceutils.resetconnectionaftertransaction(con, txobject.getpreviousisolationlevel());
}
catch (throwable ex) {
logger.debug("could not reset jdbc connection after transaction", ex);
}
if (txobject.isnewconnectionholder()) {
if (logger.isdebugenabled()) {
logger.debug("releasing jdbc connection [" + con + "] after transaction");
}
// 如果当前事务是独立的新创建的事务则在事务完成时释放数据库连接
datasourceutils.releaseconnection(con, this.datasource);
}
txobject.getconnectionholder().clear();
}
如果在事务执行前有事务挂起，那么当前事务执行结束后需要将挂起事务恢复。
如果有挂起的事务的话，status.getsuspendedresources() != null，也就是说status中会有suspendedresources这个属性，取得status中的transaction后进入resume方法：
protected final void resume(@nullable object transaction, @nullable suspendedresourcesholder resourcesholder)
throws transactionexception {
if (resourcesholder != null) {
object suspendedresources = resourcesholder.suspendedresources;
// 如果有被挂起的事务才进入
if (suspendedresources != null) {
// 真正去resume恢复的地方
doresume(transaction, suspendedresources);
}
list<transactionsynchronization> suspendedsynchronizations = resourcesholder.suspendedsynchronizations;
if (suspendedsynchronizations != null) {
// 将上面提到的transactionsynchronizationmanager专门存放线程变量的类中
// 的属性设置成被挂起事务的属性
transactionsynchronizationmanager.setactualtransactionactive(resourcesholder.wasactive);
transactionsynchronizationmanager.setcurrenttransactionisolationlevel(resourcesholder.isolationlevel);
transactionsynchronizationmanager.setcurrenttransactionreadonly(resourcesholder.readonly);
transactionsynchronizationmanager.setcurrenttransactionname(resourcesholder.name);
doresumesynchronization(suspendedsynchronizations);
}
}
}
我们来看看doresume
@override
protected void doresume(@nullable object transaction, object suspendedresources) {
transactionsynchronizationmanager.bindresource(obtaindatasource(), suspendedresources);
}
这里恢复只是把suspendedresources重新绑定到线程中。
几种事务传播属性详解
我们先来看看七种传播属性
spring事物传播特性表：
| 传播特性名称 | 说明 |
|---|---|
|
propagation_required |
如果当前没有事物，则新建一个事物；如果已经存在一个事物，则加入到这个事物中 |
|
propagation_supports |
支持当前事物，如果当前没有事物，则以非事物方式执行 |
|
propagation_mandatory |
使用当前事物，如果当前没有事物，则抛出异常 |
|
propagation_requires_new |
新建事物，如果当前已经存在事物，则挂起当前事物 |
|
propagation_not_supported |
以非事物方式执行，如果当前存在事物，则挂起当前事物 |
|
propagation_never |
以非事物方式执行，如果当前存在事物，则抛出异常 |
|
propagation_nested |
如果当前存在事物，则在嵌套事物内执行； 如果当前没有事物，则与propagation_required传播特性相同 |
当前不存在事务的情况下
每次创建一个transactioninfo的时候都会去new一个transaction，然后去线程变量map中拿holder，当此时线程变量的map中holder为空时，就视为当前情况下不存在事务，所以此时transaction中holder = null。
1、propagation_mandatory
使用当前事物，如果当前没有事物，则抛出异常
在上一篇博文中我们在gettransaction方法中可以看到如下代码，当前线程不存在事务时，如果传播属性为propagation_mandatory，直接抛出异常，因为propagation_mandatory必须要在事务中运行
if (definition.getpropagationbehavior() == transactiondefinition.propagation_mandatory) {
throw new illegaltransactionstateexception(
"no existing transaction found for transaction marked with propagation 'mandatory'");
}
2、required、requires_new、nested
我们继续看上一篇博文中的gettransaction方法
else if (definition.getpropagationbehavior() == transactiondefinition.propagation_required ||
definition.getpropagationbehavior() == transactiondefinition.propagation_requires_new ||
definition.getpropagationbehavior() == transactiondefinition.propagation_nested) {
// propagation_required、propagation_requires_new、propagation_nested都需要新建事务
// 因为此时不存在事务，将null挂起
suspendedresourcesholder suspendedresources = suspend(null);
if (debugenabled) {
logger.debug("creating new transaction with name [" + definition.getname() + "]: " + definition);
}
try {
boolean newsynchronization = (gettransactionsynchronization() != synchronization_never);
// new一个status，存放刚刚创建的transaction，然后将其标记为新事务！
// 这里transaction后面一个参数决定是否是新事务！
defaulttransactionstatus status = newtransactionstatus(
definition, transaction, true, newsynchronization, debugenabled, suspendedresources);
// 新开一个连接的地方，非常重要
dobegin(transaction, definition);
preparesynchronization(status, definition);
return status;
}
catch (runtimeexception | error ex) {
resume(null, suspendedresources);
throw ex;
}
}
此时会讲null挂起，此时的status变量为：
defaulttransactionstatus status = newtransactionstatus(definition, transaction, true, newsynchronization, debugenabled, suspendedresources);
此时的transaction中holder依然为null，标记为新事务，接着就会执行dobegin方法了：
@override
protected void dobegin(object transaction, transactiondefinition definition) {
datasourcetransactionobject txobject = (datasourcetransactionobject) transaction;
connection con = null;
// 此时会进入这个if语句块，因为此时的holder依然为null
if (!txobject.hasconnectionholder() ||
txobject.getconnectionholder().issynchronizedwithtransaction()) {
// 从datasource从取得一个新的connection
connection newcon = obtaindatasource().getconnection();
if (logger.isdebugenabled()) {
logger.debug("acquired connection [" + newcon + "] for jdbc transaction");
}
// new一个新的holder放入新的连接，设置为新的holder
txobject.setconnectionholder(new connectionholder(newcon), true);
}
// 略...
preparetransactionalconnection(con, definition);
// 将holder设置avtive = true
txobject.getconnectionholder().settransactionactive(true);
// bind the connection holder to the thread.
// 绑定到当前线程
if (txobject.isnewconnectionholder()) {
transactionsynchronizationmanager.bindresource(obtaindatasource(), txobject.getconnectionholder());
}
}
}
所以，一切都是新的，新的事务，新的holder，新的连接，在当前不存在事务的时候一切都是新创建的。
这三种传播特性在当前不存在事务的情况下是没有区别的，此事务都为新创建的连接，在回滚和提交的时候都可以正常回滚或是提交，就像正常的事务操作那样。
3、propagation_supports、propagation_not_supported、propagation_never
我们看看当传播属性为propagation_supports、propagation_not_supported、propagation_never这几种时的代码，gettransaction方法
else {
//其他的传播特性一律返回一个空事务，transaction = null
//当前不存在事务，且传播机制=propagation_supports/propagation_not_supported/propagation_never，这三种情况，创建“空”事务
boolean newsynchronization = (gettransactionsynchronization() == synchronization_always);
return preparetransactionstatus(definition, null, true, newsynchronization, debugenabled, null);
}
我们看到status中第二个参数传的是null，表示一个空事务，意思是当前线程中并没有connection，那如何进行数据库的操作呢？上一篇文章中我们有一个扩充的知识点，mybaits中使用的数据库连接是从通过transactionsynchronizationmanager.getresource(object key)获取spring增强方法中绑定到线程的connection，如下代码，那当传播属性为propagation_supports、propagation_not_supported、propagation_never这几种时，并没有创建新的connection，当前线程中也没有绑定connection，那mybatis是如何获取connecion的呢？这里留一个疑问，我们后期看mybatis的源码的时候来解决这个疑问
@nullable
public static object getresource(object key) {
object actualkey = transactionsynchronizationutils.unwrapresourceifnecessary(key);
object value = dogetresource(actualkey);
if (value != null && logger.istraceenabled()) {
logger.trace("retrieved value [" + value + "] for key [" + actualkey + "] bound to thread [" +
thread.currentthread().getname() + "]");
}
return value;
}
@nullable
private static object dogetresource(object actualkey) {
map<object, object> map = resources.get();
if (map == null) {
return null;
}
object value = map.get(actualkey);
// transparently remove resourceholder that was marked as void...
if (value instanceof resourceholder && ((resourceholder) value).isvoid()) {
map.remove(actualkey);
// remove entire threadlocal if empty...
if (map.isempty()) {
resources.remove();
}
value = null;
}
return value;
}
此时我们知道status中的transaction为null,在目标方法执行完毕后，进行回滚或提交的时候，会判断当前事务是否是新事务，代码如下
@override
public boolean isnewtransaction() {
return (hastransaction() && this.newtransaction);
}
此时transacion为null，回滚或提交的时候将什么也不做
当前存在事务情况下
上一篇文章中已经讲过，第一次事务开始时必会新创一个holder然后做绑定操作，此时线程变量是有holder的且avtive为true，如果第二个事务进来，去new一个transaction之后去线程变量中取holder，holder是不为空的且active是为true的，所以会进入handleexistingtransaction方法：
1 private transactionstatus handleexistingtransaction(
2 transactiondefinition definition, object transaction, boolean debugenabled)
3 throws transactionexception {
4 // 1.nerver（不支持当前事务;如果当前事务存在，抛出异常）报错
5 if (definition.getpropagationbehavior() == transactiondefinition.propagation_never) {
6 throw new illegaltransactionstateexception(
7 "existing transaction found for transaction marked with propagation 'never'");
8 }
9 // 2.not_supported（不支持当前事务，现有同步将被挂起）挂起当前事务,返回一个空事务
10 if (definition.getpropagationbehavior() == transactiondefinition.propagation_not_supported) {
11 if (debugenabled) {
12 logger.debug("suspending current transaction");
13 }
14 // 这里会将原来的事务挂起,并返回被挂起的对象
15 object suspendedresources = suspend(transaction);
16 boolean newsynchronization = (gettransactionsynchronization() == synchronization_always);
17 // 这里可以看到，第二个参数transaction传了一个空事务，第三个参数false为旧标记
18 // 最后一个参数就是将前面挂起的对象封装进新的status中，当前事务执行完后，就恢复suspendedresources
19 return preparetransactionstatus(definition, null, false, newsynchronization, debugenabled, suspendedresources);
20 }
21 // 3.requires_new挂起当前事务，创建新事务
22 if (definition.getpropagationbehavior() == transactiondefinition.propagation_requires_new) {
23 if (debugenabled) {
24 logger.debug("suspending current transaction, creating new transaction with name [" +
25 definition.getname() + "]");
26 }
27 // 将原事务挂起，此时新建事务，不与原事务有关系
28 // 会将transaction中的holder设置为null，然后解绑！
29 suspendedresourcesholder suspendedresources = suspend(transaction);
30 try {
31 boolean newsynchronization = (gettransactionsynchronization() != synchronization_never);
32 // new一个status出来，传入transaction，并且为新事务标记，然后传入挂起事务
33 defaulttransactionstatus status = newtransactionstatus(definition, transaction, true, newsynchronization, debugenabled, suspendedresources);
34 // 这里也做了一次dobegin，此时的transaction中holer是为空的，因为之前的事务被挂起了
35 // 所以这里会取一次新的连接，并且绑定！
36 dobegin(transaction, definition);
37 preparesynchronization(status, definition);
38 return status;
39 }
40 catch (runtimeexception beginex) {
41 resumeafterbeginexception(transaction, suspendedresources, beginex);
42 throw beginex;
43 }
44 catch (error beginerr) {
45 resumeafterbeginexception(transaction, suspendedresources, beginerr);
46 throw beginerr;
47 }
48 }
49 // 如果此时的传播特性是nested，不会挂起事务
50 if (definition.getpropagationbehavior() == transactiondefinition.propagation_nested) {
51 if (!isnestedtransactionallowed()) {
52 throw new nestedtransactionnotsupportedexception(
53 "transaction manager does not allow nested transactions by default - " +
54 "specify 'nestedtransactionallowed' property with value 'true'");
55 }
56 if (debugenabled) {
57 logger.debug("creating nested transaction with name [" + definition.getname() + "]");
58 }
59 // 这里如果是jta事务管理器，就不可以用savepoint了，将不会进入此方法
60 if (usesavepointfornestedtransaction()) {
61 // 这里不会挂起事务，说明nested的特性是原事务的子事务而已
62 // new一个status，传入transaction，传入旧事务标记，传入挂起对象=null
63 defaulttransactionstatus status =preparetransactionstatus(definition, transaction, false, false, debugenabled, null);
64 // 这里是nested特性特殊的地方，在先前存在事务的情况下会建立一个savepoint
65 status.createandholdsavepoint();
66 return status;
67 }
68 else {
69 // jta事务走这个分支，创建新事务
70 boolean newsynchronization = (gettransactionsynchronization() != synchronization_never);
71 defaulttransactionstatus status = newtransactionstatus(
72 definition, transaction, true, newsynchronization, debugenabled, null);
73 dobegin(transaction, definition);
74 preparesynchronization(status, definition);
75 return status;
76 }
77 }
78
79 // 到这里propagation_supports 或 propagation_required或propagation_mandatory，存在事务加入事务即可，标记为旧事务，空挂起
80 boolean newsynchronization = (gettransactionsynchronization() != synchronization_never);
81 return preparetransactionstatus(definition, transaction, false, newsynchronization, debugenabled, null);
82 }
1、nerver
不支持当前事务;如果当前事务存在，抛出异常
// 1.nerver（不支持当前事务;如果当前事务存在，抛出异常）报错
if (definition.getpropagationbehavior() == transactiondefinition.propagation_never) {
throw new illegaltransactionstateexception(
"existing transaction found for transaction marked with propagation 'never'");
}
我们看到如果当前线程中存在事务，传播属性为propagation_never，会直接抛出异常
2、not_supported
以非事物方式执行，如果当前存在事物，则挂起当前事物
我们看上面代码第9行，如果传播属性为propagation_not_supported，会先将原来的transaction挂起，此时status为：
return preparetransactionstatus(definition, null, false, newsynchronization, debugenabled, suspendedresources);
transaction为空，旧事务，挂起的对象存入status中。
此时与外层事务隔离了，在这种传播特性下，是不进行事务的，当提交时，因为是旧事务，所以不会commit，失败时也不会回滚rollback
3、requires_new
此时会先挂起，然后去执行dobegin方法，此时会创建一个新连接，新holder，新holder有什么用呢？
如果是新holder，会在dobegin中做绑定操作，将新holder绑定到当前线程，其次，在提交或是回滚时finally语句块始终会执行清理方法时判断新holder会进行解绑操作。
@override
protected void docleanupaftercompletion(object transaction) {
datasourcetransactionobject txobject = (datasourcetransactionobject) transaction;
// remove the connection holder from the thread, if exposed.
if (txobject.isnewconnectionholder()) {
transactionsynchronizationmanager.unbindresource(obtaindatasource());
}
}
符合传播特性，所以这里requires_new这个传播特性是与原事务相隔的，用的连接都是新new出来的。
此时返回的status是这样的：
defaulttransactionstatus status = newtransactionstatus(definition, transaction, true, newsynchronization, debugenabled, suspendedresources);
其中transaction中holder为新holder，连接都是新的。标记为新事务，在开头的回顾中提到，如果是新事务，提交时才能成功提交。并且在最后一个参数放入挂起的对象，之后将会恢复它。
requires_new小结
会于前一个事务隔离，自己新开一个事务，与上一个事务无关，如果报错，上一个事务catch住异常，上一个事务是不会回滚的，这里要注意(在invokewithintransaction方法中的catch代码块中，处理完异常后，还通过 throw ex;将异常抛给了上层，所以上层要catch住子事务的异常，子事务回滚后，上层事务也会回滚)，而只要自己提交了之后，就算上一个事务后面的逻辑报错，自己是不会回滚的（因为被标记为新事务，所以在提交阶段已经提交了）。
4、nested
不挂起事务，并且返回的status对象如下：
defaulttransactionstatus status =preparetransactionstatus(definition, transaction, false, false, debugenabled, null); status.createandholdsavepoint();
不同于其他的就是此传播特性会创建savepoint，有什么用呢？前面说到，如果是旧事务的话回滚是不会执行的，但先看看它的status，虽然标记为旧事务，但它还有savepoint，如果有savepoint，会回滚到保存点去，提交的时候，会释放保存点，但是不提交！切记，这里就是nested与requires_new不同点之一了，nested只会在外层事务成功时才进行提交，实际提交点只是去释放保存点，外层事务失败，nested也将回滚，但如果是requires_new的话，不管外层事务是否成功，它都会提交不回滚。这就是savepoint的作用。
由于不挂起事务，可以看出来，此时transaction中的holder用的还是旧的，连接也是上一个事务的连接，可以看出来，这个传播特性会将原事务和自己当成一个事务来做。
nested 小结
与前一个事务不隔离，没有新开事务，用的也是老transaction，老的holder，同样也是老的connection，没有挂起的事务。关键点在这个传播特性在存在事务情况下会创建savepoint，但不存在事务情况下是不会创建savepoint的。在提交时不真正提交，只是释放了保存点而已，在回滚时会回滚到保存点位置，如果上层事务catch住异常的话，是不会影响上层事务的提交的，外层事务提交时，会统一提交，外层事务回滚的话，会全部回滚
5、required 、propagation_required或propagation_mandatory
存在事务加入事务即可，标记为旧事务，空挂起
status为：
return preparetransactionstatus(definition, transaction, false, newsynchronization, debugenabled, null);
使用旧事务，标记为旧事务，挂起对象为空。
与前一个事务不隔离，没有新开事务，用的也是老transaction，老的connection，但此时被标记成旧事务，所以，在提交阶段不会真正提交的，在外层事务提交阶段，才会把事务提交。
如果此时这里出现了异常，内层事务执行回滚时，旧事务是不会去回滚的，而是进行回滚标记，我们看看文章开头处回滚的处理函数processrollback中第39行，当前事务信息中表明是存在事务的，但是既没有保存点，又不是新事务，回滚的时候只做回滚标识，等到提交的时候再判断是否有回滚标识，commit的时候，如果有回滚标识，就进行回滚
@override
protected void dosetrollbackonly(defaulttransactionstatus status) {
// 将status中的transaction取出
datasourcetransactionobject txobject = (datasourcetransactionobject) status.gettransaction();
if (status.isdebug()) {
logger.debug("setting jdbc transaction [" + txobject.getconnectionholder().getconnection() +
"] rollback-only");
}
// transaction执行标记回滚
txobject.setrollbackonly();
}
public void setrollbackonly() {
// 这里将transaction里面的connholder标记回滚
getconnectionholder().setrollbackonly();
}
public void setrollbackonly() {
// 将holder中的这个属性设置成true
this.rollbackonly = true;
}
我们知道，在内层事务中transaction对象中的holder对象其实就是外层事务transaction里的holder，holder是一个对象，指向同一个地址，在这里设置holder标记，外层事务transaction中的holder也是会被设置到的，在外层事务提交的时候有这样一段代码：
@override
public final void commit(transactionstatus status) throws transactionexception {
// 略...
// !shouldcommitonglobalrollbackonly()只有jta与jpa事务管理器才会返回false
// defstatus.isglobalrollbackonly()这里判断status是否被标记了
if (!shouldcommitonglobalrollbackonly() && defstatus.isglobalrollbackonly()) {
if (defstatus.isdebug()) {
logger.debug("global transaction is marked as rollback-only but transactional code requested commit");
}
// 如果内层事务抛异常，外层事务是会走到这个方法中的，而不是去提交
processrollback(defstatus, true);
return;
}
// 略...
}
在外层事务提交的时候是会去验证transaction中的holder里是否被标记rollback了，内层事务回滚，将会标记holder，而holder是线程变量，在此传播特性中holder是同一个对象，外层事务将无法正常提交而进入processrollback方法进行回滚，并抛出异常：
private void processrollback(defaulttransactionstatus status, boolean unexpected) {
try {
// 此时这个值为true
boolean unexpectedrollback = unexpected;
try {
triggerbeforecompletion(status);
if (status.hassavepoint()) {
if (status.isdebug()) {
logger.debug("rolling back transaction to savepoint");
}
status.rollbacktoheldsavepoint();
}
// 新事务，将进行回滚操作
else if (status.isnewtransaction()) {
if (status.isdebug()) {
logger.debug("initiating transaction rollback");
}
// 回滚！
dorollback(status);
}
// 略...
// raise unexpectedrollbackexception if we had a global rollback-only marker
// 抛出一个异常
if (unexpectedrollback) {
// 这个就是上文说到的抛出的异常类型
throw new unexpectedrollbackexception(
"transaction rolled back because it has been marked as rollback-only");
}
}
finally {
cleanupaftercompletion(status);
}
}
上一篇： MyBatis逆向工程有关错误
下一篇： if判断语句的总结
推荐阅读
-
spring5 源码深度解析----- @Transactional注解的声明式事物介绍（100%理解事务）
-
spring5 源码深度解析----- 事务增强器（100%理解事务）
-
spring5 源码深度解析----- 事务的回滚和提交（100%理解事务）
-
spring5 源码深度解析----- AOP目标方法和增强方法的执行（100%理解AOP）
-
spring5 源码深度解析----- Spring事务 是怎么通过AOP实现的？（100%理解Spring事务）
-
spring5 源码深度解析----- @Transactional注解的声明式事物介绍（100%理解事务）
-
spring5 源码深度解析----- 事务增强器（100%理解事务）