Spring声明式事务管理源码解读之事务开始

/**
*作者：张荣华(ahuaxuan)
*2007-06-16
*转载请注明出处及作者
*/

Spring声明式事务管理源码解读

简介：事务是所有企业应用系统的核心，之前人们使用ejb的时候，容器事务管理(CMT)，是slsb最令人称道的地方，据说很多人使用ejb，使用slsb就是为了cmt，但是spring出现之后，格局就变了，因为程序员又多了一种选择，就是声明式事务管理，声明式事务管理是基于AOP的，及AOP是它的底层特性，本文的目的就是为了和大家探讨一下spring的声明式事务管理，从源代码来分析它的背后的思想。（谢谢异常的建议，因为本文原来没有简介）


这个是我昨天在解决问题是看源码得一点体验，可能说得比较大概，希望大家多多讨论，把本贴得质量提高上去，因为spring实现的事务管理这部分我相信还是有点复杂的。一个人未必能想得十分清楚
在spring的声明式事务管理中，它是如何判定一个及标记一个方法是否应该是处在事务体之中呢。

首先要理解的是spring是如何来标记一个方法是否应该处在事务体之中的。有这样一个接口TransactionDefinition，其中定义了很多常量，它还有一个子接口TransactionAttribute，其中只有一个方法rollback。
TransactionDefinition中有很多常量定义，它们分别属于两种类型，传播途径和隔离级别

/**
	 * Support a current transaction, create a new one if none exists.
	 * Analogous to EJB transaction attribute of the same name.
	 * <p>This is typically the default setting of a transaction definition.
	 */
	int PROPAGATION_REQUIRED = 0;

当然其中也定义了隔离级别
/**

 * A constant indicating that dirty reads are prevented; non-repeatable reads
	 * and phantom reads can occur. This level only prohibits a transaction
	 * from reading a row with uncommitted changes in it.
	 * @see java.sql.Connection#TRANSACTION_READ_COMMITTED
	 */
	int ISOLATION_READ_COMMITTED   = Connection.TRANSACTION_READ_COMMITTED;

同时还有两个对应的方法来得到这样的传播途径和隔离级别

/**
	 * Return the propagation behavior.
	 * Must return one of the PROPAGATION constants.
	 * @see #PROPAGATION_REQUIRED
	 * @see org.springframework.transaction.support.TransactionSynchronizationManager#isActualTransactionActive()
	 */
	int getPropagationBehavior();

	/**
	 * Return the isolation level.
	 * Must return one of the ISOLATION constants.
	 * <p>Only makes sense in combination with PROPAGATION_REQUIRED or
	 * PROPAGATION_REQUIRES_NEW.
	 * <p>Note that a transaction manager that does not support custom
	 * isolation levels will throw an exception when given any other level
	 * than ISOLATION_DEFAULT.
	 * @see #ISOLATION_DEFAULT
	 */
	int getIsolationLevel();

这个接口有一个默认的实现DefaultTransactionDefinition。然后它还有子类，比如说
DefaultTransactionAttribute。Spring在判断一个方法是否需要事务体的时候其实是创建一个TransactionAttribute实现的实例.

有了上面的简单介绍就可以进入真正判断是否需要事务的地方了。这个方法在TransactionAspectSupport类里，

/**
	 * Create a transaction if necessary.
	 * @param method method about to execute
	 * @param targetClass class the method is on
	 * @return a TransactionInfo object, whether or not a transaction was created.
	 * The hasTransaction() method on TransactionInfo can be used to tell if there
	 * was a transaction created.
	 */
	protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {
		// If the transaction attribute is null, the method is non-transactional.
		final TransactionAttribute sourceAttr =
				this.transactionAttributeSource.getTransactionAttribute(method, targetClass);//就是在这里判断了这个方法的事务属性
		TransactionAttribute txAttr = sourceAttr;

		// If no name specified, apply method identification as transaction name.
		if (txAttr != null && txAttr.getName() == null) {
			final String name = methodIdentification(method);
			txAttr = new DelegatingTransactionAttribute(sourceAttr) {
				public String getName() {
					return name;
				}
			};
		}

		TransactionInfo txInfo = new TransactionInfo(txAttr, method);
//TransactionInfo是TransactionAspectSupport的一个内部类，它的主要功能是记录方法和对应的事务属性
		if (txAttr != null) {
			// We need a transaction for this method
			if (logger.isDebugEnabled()) {
				logger.debug("Getting transaction for " + txInfo.joinpointIdentification());
			}

			// The transaction manager will flag an error if an incompatible tx already exists
			txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));//这个方法要仔细的看
		}
		else {
			// The TransactionInfo.hasTransaction() method will return
			// false. We created it only to preserve the integrity of
			// the ThreadLocal stack maintained in this class.
			if (logger.isDebugEnabled())
				logger.debug("Don't need to create transaction for [" + methodIdentification(method) +
						"]: this method isn't transactional");
		}

		// We always bind the TransactionInfo to the thread, even if we didn't create
		// a new transaction here. This guarantees that the TransactionInfo stack
		// will be managed correctly even if no transaction was created by this aspect.
		txInfo.bindToThread();
		return txInfo;
	}

TransactionInfo是TransactionAspectSupport的一个内部类，它的主要功能是记录方法和对应的事务属性，在上面这个方法的最后，这个TransactionInfo对象被保存到当前线程中。

而这个方法会在事务拦截器TransactionInterceptor中被调用，TransactionInterceptor实际上是TransactionAspectSupport的子类，看看其中的invoke方法：

// Work out the target class: may be <code>null</code>.
		// The TransactionAttributeSource should be passed the target class
		// as well as the method, which may be from an interface
		Class targetClass = (invocation.getThis() != null) ? invocation.getThis().getClass() : null;
		
		// Create transaction if necessary.
		TransactionInfo txInfo = createTransactionIfNecessary(invocation.getMethod(), targetClass);

		Object retVal = null;
		try {
			// This is an around advice.
			// Invoke the next interceptor in the chain.
			// This will normally result in a target object being invoked.
			retVal = invocation.proceed();
		}
		catch (Throwable ex) {
			// target invocation exception
			doCloseTransactionAfterThrowing(txInfo, ex);
			throw ex;
		}
		finally {
			doFinally(txInfo);
		}
		doCommitTransactionAfterReturning(txInfo);//在这里执行方法结束之后需要的操作
		return retVal;

这个方法就如同一般的interceptor需要实现的方法一样。只不过在这个方法里判断被反射的方法是否需要事务。

接着我们重点再回头看一下createTransactionIfNecessary方法里的这一句：
txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
接着我们就应该去看看这个getTransaction方法了，假设我们是使用hibernate3，其他类似。看getTransaction之前我们来看一下这两类和一个接口
接口PlatformTransactionManager
抽象类public abstract class AbstractPlatformTransactionManager implements PlatformTransactionManager
类public class HibernateTransactionManager extends AbstractPlatformTransactionManager，很明显，这里有一个方法模板模式。
那我们看一下AbstractPlatformTransactionManager中得getTransaction方法：

public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {
		Object transaction = doGetTransaction();//抽象方法，也需要子类实现,这个方法同样很重要

		// Cache debug flag to avoid repeated checks.
		boolean debugEnabled = logger.isDebugEnabled();
		if (debugEnabled) {
			logger.debug("Using transaction object [" + transaction + "]");
		}

		if (definition == null) {
			// Use defaults if no transaction definition given.
			definition = new DefaultTransactionDefinition();
		}

		if (isExistingTransaction(transaction)) {
			// Existing transaction found -> check propagation behavior to find out how to behave.
			return handleExistingTransaction(definition, transaction, debugEnabled);
		}

		// Check definition settings for new transaction.
		if (definition.getTimeout() < TransactionDefinition.TIMEOUT_DEFAULT) {
			throw new InvalidTimeoutException("Invalid transaction timeout", definition.getTimeout());
		}

		// No existing transaction found -> check propagation behavior to find out how to behave.
		if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_MANDATORY) {
			throw new IllegalTransactionStateException(
					"Transaction propagation 'mandatory' but no existing transaction found");
		}
		else if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||
				definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||
		    definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
			if (debugEnabled) {
				logger.debug("Creating new transaction with name [" + definition.getName() + "]");
			}
			doBegin(transaction, definition);
			boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER);
			return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);
		}
		else {
			// Create "empty" transaction: no actual transaction, but potentially synchronization.
			boolean newSynchronization = (this.transactionSynchronization == SYNCHRONIZATION_ALWAYS);
			return newTransactionStatus(definition, null, false, newSynchronization, debugEnabled, null);
		}
	}

上面的代码很多地方都有解释，所以很好理解，这段代码的关键部分在doBegin(transaction,definition)这里（这是一个抽象方法，子类必须实现这个方法，
具体依赖于抽象，这个是对方法模板模式的一个概括。），前面讲到我们假设是使用hibernate，那么就看看HibernateTransactionManager这个类吧，doBegin里的参数1，transaction其实是HibernateTransactionObject的一个实例，这个实例里主要存放的就是sessionholder，sessionholder里存放的就是开始事务的session和transaction对象,如果之前没有sessionholder存放到线程中，那么这个HibernateTransactionObject的实例的属性其实是空的，这一点可以在doBegin方法的实现中看出来

protected void doBegin(Object transaction, TransactionDefinition definition) {
		if (getDataSource() != null && TransactionSynchronizationManager.hasResource(getDataSource())) {
			throw new IllegalTransactionStateException(
					"Pre-bound JDBC Connection found - HibernateTransactionManager does not support " +
					"running within DataSourceTransactionManager if told to manage the DataSource itself. " +
					"It is recommended to use a single HibernateTransactionManager for all transactions " +
					"on a single DataSource, no matter whether Hibernate or JDBC access.");
		}

		Session session = null;

		try {
			HibernateTransactionObject txObject = (HibernateTransactionObject) transaction;
			if (txObject.getSessionHolder() == null) {
				Interceptor entityInterceptor = getEntityInterceptor();
				Session newSession = (entityInterceptor != null ?
						getSessionFactory().openSession(entityInterceptor) : getSessionFactory().openSession());
				if (logger.isDebugEnabled()) {
					logger.debug("Opened new Session [" + newSession + "] for Hibernate transaction");
				}
				txObject.setSessionHolder(new SessionHolder(newSession), true);

}//我们看到，如果传进来的transaction中并没有存放sessionholder，那么就新建一个session，放到新的sessionholder中，再放到HibernateTransactionObject的实例中去,顺便说一下，这个变量的名字取得真是差，虽然是Juergen Hoeller写的，也要批一下，搞得别人会以为是Transaction的实例

txObject.getSessionHolder().setSynchronizedWithTransaction(true);
			session = txObject.getSessionHolder().getSession();

			Connection con = session.connection();
			Integer previousIsolationLevel = DataSourceUtils.prepareConnectionForTransaction(con, definition);
			txObject.setPreviousIsolationLevel(previousIsolationLevel);

			if (definition.isReadOnly() && txObject.isNewSessionHolder()) {
				// Just set to NEVER in case of a new Session for this transaction.
				session.setFlushMode(FlushMode.NEVER);
			}//如果是只读事务，并且sessionholder是新建的，那么就设置hibernate的flushmode为never

			if (!definition.isReadOnly() && !txObject.isNewSessionHolder()) {
				// We need AUTO or COMMIT for a non-read-only transaction.
				FlushMode flushMode = session.getFlushMode();
				if (FlushMode.NEVER.equals(flushMode)) {
					session.setFlushMode(FlushMode.AUTO);
//如果session的flushmode是nerver，就设置为auto，因为如果事务定义成非readonly，那么这个session一定是可以flush的
					txObject.getSessionHolder().setPreviousFlushMode(flushMode);
				}
			}

			// Add the Hibernate transaction to the session holder.
			txObject.getSessionHolder().setTransaction(session.beginTransaction())；//开始一个事务，并把这个事务对象放到sessionholder中，随后这个sessionholder会通过threadlocal放到线程中，以供在commit时使用

			// Register transaction timeout.
			if (definition.getTimeout() != TransactionDefinition.TIMEOUT_DEFAULT) {
				txObject.getSessionHolder().setTimeoutInSeconds(definition.getTimeout());//设置超时时间,如果其超时时间为-1，则不进行设置，如果不是-1，那么超时时间是这样设置的new Date(System.currentTimeMillis() + millis*1000);既程序员在配置文件中指定的其实是秒数
			}

			// Register the Hibernate Session's JDBC Connection for the DataSource, if set.
			if (getDataSource() != null) {
				ConnectionHolder conHolder = new ConnectionHolder(con);
				if (definition.getTimeout() != TransactionDefinition.TIMEOUT_DEFAULT) {
					conHolder.setTimeoutInSeconds(definition.getTimeout());
				}
				if (logger.isDebugEnabled()) {
					logger.debug("Exposing Hibernate transaction as JDBC transaction [" + con + "]");
				}
				TransactionSynchronizationManager.bindResource(getDataSource(), conHolder);
				txObject.setConnectionHolder(conHolder);
			}

			// Bind the session holder to the thread.
			if (txObject.isNewSessionHolder()) {
				TransactionSynchronizationManager.bindResource(getSessionFactory(), txObject.getSessionHolder());//如果是新的sessionholder则绑定到线程。这样在进入方法栈中的下一个方法时就能得到整个sessionholder了，connectionholder亦是如此
			}
		}
catch (Exception ex) {
			SessionFactoryUtils.releaseSession(session, getSessionFactory());//如果抛出异常就释放这个session,这个操作还会在后面出现
			throw new CannotCreateTransactionException("Could not open Hibernate Session for transaction", ex);
		}
	}

通过以上对代码的注释可以知道，如果给service设置声明式事务管理，假设事务传播途径为required，然后一个service调用另一个service时，他们其实是共用一个session，原则是没有就创建，有就不创建，并返回之前已创建的session和transaction。也就是说spring通过threadlocal把session和对应的transaction放到线程之中，保证了在整个方法栈的任何一个地方都能得到同一个session和transaction。
所以如果你的方法在事务体之内，那么你只要通过hibernatesupportdao或者hibernatetemplate来得到session的话，那这个session一定是开始事务的那个session，这个得到session的主要方法在SessionFactoryUtils里，我们来看一下
（这里还有一个小细节，public abstract class SessionFactoryUtils ，Juergen Hoeller在写工具类的时候为了不能让其有实例使用的是abstract，而我们一般的做法是final类加private的构造方法，看上去不怎么雅观,看看源代码还是能学习到不少写代码的技巧的,这里还有一个插曲，上次feiing还说java为什么不能弄成final和abstract同时存在呢，这样就可以确保既不会有实例产生，也不能继承了，呵呵）
在SessionFactoryUtils的doGetSession里写到，如果当前线程有绑定session，则返回这个session，如果没有绑定session，则看是否允许创建（既allowCreate这个参数是true还是false，这个参数将会在很多地方设计到，比如说hibernatetemplate和hibernatedaosupport里都有），如果不允许创建就抛出一个原始的hibernateException，举个例子，如果你没有给某个service方法配置声明式事务管理，而却要在这个service所调用的dao里得到当前得session，这样就会抛这个错了：

if (method.getName().equals("getCurrentSession")) {
				// Handle getCurrentSession method: return transactional Session, if any.
				try {
					return SessionFactoryUtils.doGetSession((SessionFactory) proxy, false);
//最后一个参数是false，说明这个方法不能返回一个新的session，没有就抛异常
				}
				catch (IllegalStateException ex) {
					throw new HibernateException(ex.getMessage());
				}
			}

到这里事务开始部分基本就结束了
按正常流程，那么接下来就是方法结束commit的问题了。Commit放到下一篇文章里说吧

我会把大家正确得观点不断得加到贴中，使本贴得质量不断提高，共同进步吧，使劲的拍吧

俺写文章得水平是不行的，希望大家也多提提写文章技巧方面的意见

修改：这篇文章的后续篇(spring声明式事务源码解读之事务提交)已经完成：
http://www.iteye.com/topic/89072


作者：张荣华，未经作者同意不得随意转载！

由于读源码的热潮被掀起来了。
但没几个人会写简介。。。

如果把API翻一下就会发现根本不用去读源码，
而大多数人去读源码是由于对API翻译的不满 ：

这翩文章的中心想法是：
1.TransactionDefinition接口；
本接口就是放一些关键的常量定义的
包括：（传播途径和隔离级别）
（TransactionAttribute会用到PS：我认为这个接口与上面接口无逻辑关，可以不用说）
2. DefaultTransactionDefinition是默认的实现
DefaultTransactionAttribute也是实现方式
（逻辑关系不可考）

－－－－－－－－－－－－－－－－－分割线－－－－－－－－－－－－－－－


3.TransactionAspectSupport
中的一个方法（为什么没有方法名？）
看一个事务是否已经被创建（？没看明白）如果没有就创建一个
4.TransactionInfo由前一个反回的实例，里面全是些状态位，它的主要功能是记录方法和对应的事务属性

5.TransactionInterceptor(没看懂。。。)在这个方法里判断被反射的方法是否需要事务
6.txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));
（喝了点酒。。。看不懂的明天再看吧。。。）

漂亮的解读，漂亮的分析。加上Session和Connection的生命周期分析就更完美了。

针对Session和Connection都有不同的获取方式

这个需要功力极高的高手才能做到，一般人估计达不到这个境界吧


仔细阅读dobegin方法啊


不是，是否需要事务是已经配置好的，在配置文件中，是否需要事务在createifnessary方法里

protected class TransactionInfo {

		private final TransactionAttribute transactionAttribute;

		// TODO: Could open up to other kinds of joinpoint?
		private final Method method;

		private TransactionStatus transactionStatus;
}

transactionstatus是记录事务状态的类，比如说事务是否是新事务，事务是否已经结束了。

谢谢大家的关注，谢谢异常的意见，这个简介我会抽空补上去

俺觉得分析session和connection的生命周期最好是放在hibernate的源码分析里，可惜hibernate源码俺只看过一些些，最主要的是对这个感兴趣的人不多，上次俺写了一篇扩展hibernate，使用自定义集合类的文章，结果没一个人理，感觉挺失落，呵呵

没办法啊这是个快餐的社会。。。
如果没有足够的耐心很难静下来看源码的。。。。
（我也一样）
对于不同的人需求也不一样
有的人需要了解用法（要看中文的API但翻译的不好只好看源码）
有人要对正在使用的框架进行扩展（已经对API了解很透，这些人喜欢看接口的中文简介。应该给出一些流程的图解给他们。。）

有的人想要找到鬼怪毛病的原因（他们想要看源码，但又没有时间把所有的源码都看完。。。所以要有一个索引让他能够立刻找到想看的源码）

有的人想要想作自己的框架想作些参考（这些人以学生剧多。。。）

to: 异常
简介已加，已注明，呵呵，3x

因为多数情况下，会结合OpenSessionInView模式，所以这个还是非常有意义的。而且使用OpenSessionInView模式和不使用，Session和Connection的生命周期完全不同，了解了这个，基本上可以对事务和数据库连接有了一个大概的概念。

俺觉得看了你的那篇osiv详解，就都明白了啊，呵呵
刚才看了一下hibernate的SessionImpl，4千多行，我一看就对它没有什么兴趣了，given king的代码和Juergen Hoeller还有rod的代码差距太大了。