这个项目我们已经已经开过1.0了，整体反响非常不错，稍微小打小闹的学员，每天都可以收入30-50，做的好一点的人，一天收入50-100+。
这个项目很简单，我们做的就是流量主的广告收益，单片阅读1000左右可以给你带来十几二十的收益，比其他自媒体平台的广告收益要高的太多了。可以说完全是做的被动收益，只需要每天抽出半小时发发文章就行！
hi，各位同学大家好，今天来给大家讲解下spring框架事务的原理。
spring事务有配置文件和注解两种方法，配置文件方式原理这里就不做过多的介绍，本次重点解释注解@Transactional的原理。
一：注解@Transactional的执行原理过程：
1、服务器启动时进行注解扫描，将所有带有@Transactional的方法都生成一个aop代理对象；
2、调用者在调用方法时，被切入到aop中，实际调用的是aop的代理对象；
3、在aop代理对象中开启了jdbc事务，并调用了真实的方法；
4、aop代理对象得到方法执行的情况作出提交或回滚的操作。
二：为什么抛出异常后事务回滚失败？
某些情况下明明出现异常，并且抛出了，但是回滚却失败了，这是怎么回事呢，要了解这个问题我们就需要深入解读spring的事务源码，其中关键核心的源码在org.springframework.transaction.interceptor.TransactionAspectSupport，其中的方法invokeWithinTransaction控制着事务的逻辑，源码如下：
protected Object invokeWithinTransaction(Method method, Class<?> targetClass, final TransactionAspectSupport.InvocationCallback invocation) throws Throwable {
final TransactionAttribute txAttr = this.getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
final PlatformTransactionManager tm = this.determineTransactionManager(txAttr);
final String joinpointIdentification = this.methodIdentification(method, targetClass, txAttr);
Object result;
if (txAttr != null && tm instanceof CallbackPreferringPlatformTransactionManager) {
final TransactionAspectSupport.ThrowableHolder throwableHolder = new TransactionAspectSupport.ThrowableHolder();
try {
result = ((CallbackPreferringPlatformTransactionManager)tm).execute(txAttr, new TransactionCallback<Object>() {
public Object doInTransaction(TransactionStatus status) {
TransactionAspectSupport.TransactionInfo txInfo = TransactionAspectSupport.this.prepareTransactionInfo(tm, txAttr, joinpointIdentification, status);
Object var4;
try {
Object var3 = invocation.proceedWithInvocation();
return var3;
} catch (Throwable var8) {
if (txAttr.rollbackOn(var8)) {
if (var8 instanceof RuntimeException) {
throw (RuntimeException)var8;
}
throw new TransactionAspectSupport.ThrowableHolderException(var8);
}
throwableHolder.throwable = var8;
var4 = null;
} finally {
TransactionAspectSupport.this.cleanupTransactionInfo(txInfo);
}
return var4;
}
});
if (throwableHolder.throwable != null) {
throw throwableHolder.throwable;
} else {
return result;
}
} catch (TransactionAspectSupport.ThrowableHolderException var18) {
throw var18.getCause();
} catch (TransactionSystemException var19) {
if (throwableHolder.throwable != null) {
this.logger.error("Application exception overridden by commit exception", throwableHolder.throwable);
var19.initApplicationException(throwableHolder.throwable);
}
throw var19;
} catch (Throwable var20) {
if (throwableHolder.throwable != null) {
this.logger.error("Application exception overridden by commit exception", throwableHolder.throwable);
}
throw var20;
}
} else {
TransactionAspectSupport.TransactionInfo txInfo = this.createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
try {
//1.执行调用链，循环调用执行前置方法，真实方法
result = invocation.proceedWithInvocation();
} catch (Throwable var16) {
//1.2出现异常后，进行处理，回滚事务
this.completeTransactionAfterThrowing(txInfo, var16);
throw var16;
} finally {
this.cleanupTransactionInfo(txInfo);
}
//2.方法执行顺利，调用后置方法，提交事务
this.commitTransactionAfterReturning(txInfo);
return result;
}
}
其中最关键的几行代码我在上面进行了注释，总体的逻辑是先执行一些真实方法的前置切面，再执行真实方法，如果有异常就进行处理（事务回滚），如果没有异常就提交事务，并执行后置增强方法。
所以，要了解事务回滚失败的原因，就需要进一步的探究方法 this.completeTransactionAfterThrowing(txInfo, var16)，源码如下：
protected void completeTransactionAfterThrowing(TransactionAspectSupport.TransactionInfo txInfo, Throwable ex) {
if (txInfo != null && txInfo.hasTransaction()) {
if (this.logger.isTraceEnabled()) {
this.logger.trace("Completing transaction for [" + txInfo.getJoinpointIdentification() + "] after exception: " + ex);
}
if (txInfo.transactionAttribute.rollbackOn(ex)) {
try {
txInfo.getTransactionManager().rollback(txInfo.getTransactionStatus());
} catch (TransactionSystemException var7) {
this.logger.error("Application exception overridden by rollback exception", ex);
var7.initApplicationException(ex);
throw var7;
} catch (RuntimeException var8) {
this.logger.error("Application exception overridden by rollback exception", ex);
throw var8;
} catch (Error var9) {
this.logger.error("Application exception overridden by rollback error", ex);
throw var9;
}
} else {
try {
txInfo.getTransactionManager().commit(txInfo.getTransactionStatus());
} catch (TransactionSystemException var4) {
this.logger.error("Application exception overridden by commit exception", ex);
var4.initApplicationException(ex);
throw var4;
} catch (RuntimeException var5) {
this.logger.error("Application exception overridden by commit exception", ex);
throw var5;
} catch (Error var6) {
this.logger.error("Application exception overridden by commit error", ex);
throw var6;
}
}
}
}
从源码中可以看出，所处理的都是运行时RuntimeException异常及其之类的异常，也正是这个原因，一些非运行时异常抛出时，spring并未处理，所以没有回滚。
异常集成关系图，如下：
由上图可以看出像IO，SQL异常如果不进行特定的处理是不会进行事务回滚的。
在源码中，我们还注意到一行细节代码txInfo.getTransactionStatus()，就是执行事务时是根据事务状态来的，这也就有了为什么手动回滚事务的代码是这么写的：
TransactionAspectSupport.currentTransactionStatus().setRollbackOnly();
点进去源码可以看到，事务状态默认是false（提交的意思），调用此方法后，则改成true（回滚）
public abstract class AbstractTransactionStatus implements TransactionStatus {
private boolean rollbackOnly = false;
private boolean completed = false;
private Object savepoint;
public AbstractTransactionStatus() {
}
public void setRollbackOnly() {
this.rollbackOnly = true;
}
………………
由此，综上所述，spring事务回滚的原因有两个：
1、抛出的异常是非运行时异常RuntimeException；
2、事务状态被人为的修改。
那么有没有办法解决此问题了？
当然有啦，如果是人为的，只需找到对应代码调整或删除即可；
如果是非运行异常的抛出，spring针对此问题也做了解决方案，有两种方案
1、配置rollbackFor：
@Transactional(rollbackFor = Exception.class)
2、手动回滚事务
在抓取异常后，补仓代码：TransactionAspectSupport.currentTransactionStatus().setRollbackOnly(); 最后抛出异常即可。
rollbackFor是告知spring框架，要抓取非运行时异常，并回滚。=Exception.class是告知spring框架抓取的范围是什么。所以我们也可以自定义异常，只抓取特定的异常进行回滚。