spring 声明式事务原理解读

在Spring中，声明式事务是通过事务属性(transaction attribute)来定义的。事务属性描述了事务策略如何应用到方法上。事务属性包含5个方面：

• 传播行为
• 隔离级别
• 是否只读
• 事务超时
• 回滚规则

尽管Spring提供了多种声明式事务的机制，但是所有的方式都依赖这五个参数来控制如何管理事务策略。

（上述内容参考《Spring In Action》第三版）。

对于声明式事务是使用Spring提供的tx配置命名空间。其中一些声明式事务配置元素依赖于部分Spring的AOP配置元素。

下面是一个具体配置的例子：

其中是用来声明事务性策略的。对于来说，事务属性定义在元素中，该元素包含了一个或多个的元素。元素为某个（或某些）name属性（使用通配符）指定的方法定义事务的参数。

当使用来声明事务时，你还需要一个事务管理器，就像使用TransactionProxyFactoryBean那样。根据约定优于配置，假定事务管理器被声明为一个id为transactionManager的Bean。如果碰巧为事务管理器配置了一个不同的id（如txManager）,则需要在transaction-manager属性中明确指定事务管理器的id：

	  
        ...
    

只是定义了AOP通知，用于把事务边界通知给方法。但是这只是事务通知，而不是完整的事务性切面。我们在中没有声明哪些Bean应该被通知——我们需要一个切点来做这件事。为了完整定义事务性切面，我们必须定义一个通知器（advisor）。这就涉及aop命名空间了。通过上面的配置示例可以看到：

这里的pointcut属性使用了AspectJ切入点表达式来表明通知器适用于com.cetc.datamc.app.collect.bs和com.cetc.datamc.app.mdms.bs包下的所有类的所有方法。哪些方法应该真正运行在事务中以及方法的事务属性都是由这个事务通知来定义的。而事务通知是advice-ref属性来指定的，它引用了名为txAdviceHibernate的通知。

在这里有一点需要注意的是对于切面的织入，不是说只有在中配置的方法才会被织入切面。根据切面的原理，是在pointcut中配置的符合条件的目标对象都会被织入切面。Spring中是基于动态代理的方式来实现切面的，所以Spring中的切面是由包裹了目标对象的代理类实现。代理类处理方法的调用，执行额外的切面逻辑。直到应用需要被代理的Bean时，Spring才创建代理对象。如果使用的是ApplicationContext，在ApplicationContext从BeanFactory中加载所有Bean时，Spring创建被代理的对象。这时候，所有符合在pointcut中配置的类的相关方法就会被织入切面代码，并且返回相关的动态代理对象。所以说不管有没有在中配置相关方法，只要符合pointcut中的条件，方法就会被织入切面代码。

因此，在上面的例子中，所有的com.cetc.datamc.app.collect.bs和com.cetc.datamc.app.mdms.bs包中所有类的所有方法都会被织入事务管理的相关切面代码。

在创建好动态代理后，之前所有依赖注入的相关接口的实现类就会替换为创建的动态代理类。这样程序在使用接口调用时，就会调用到织入切面代码的动态代理类实现。

因此，在使用声明式事务的时候也需要注意，所有需要管理事务的类必须通过spring context管理，直接new的对象不行。 所有需要事务管理的类必须使用interface,这样动态代理才有用。

例如假设在com.cetc.datamc.app.collect.bs包中有下面的类

public interface IDataCollect {
	public String addDataItem(String data);
} 

public class DataCollectService implements IDataCollect { 
	private IMetadataService metaService;
	
	public void setMetaService(IMetadataService metaService) {
		this.metaService = metaService;
	}
	
	public String addDataItem(String data) {
		metaService.deleteMeta(data);
		return metaService.addMeta(data);
	}
}

public interface IMetadataService {
	public void deleteMeta(String data);
	public String addMeta(String data);
	public String queryMetaId(String data);
} 

public class MetadataService implements IMetadataService {
	public void deleteMeta(String data) {
		System.out.println("delete metadata");
	}
	
	public String addMeta(String data) {
		System.out.println("add metadata");
		String id = queryMetaId(data);
		return data;
	}
	
	public String queryMetaId(String data) {
		return "id";
	}
}

这样，在DataCollectService中有一个 IMetadataService类型的对象。那么在实际中该类型则是被Spring替换为动态代理对象，而不是原来的MetaService对象。所以调用了IMetadataService中的deleteMeta和addMeta方法，这两个方法都是调用的织入事务切面代码的函数。而不是原来的 deleteMeta和addMeta方法。

另外在MetaService还可以看到addMeta中调用了queryMetaId方法。这个方法调用的就是没有织入切面代码的原来的函数。因为这个不是使用接口调用的，而是直接调用的对象本身的方法。所以就是该对象原来的queryMetaId方法。这就是为什么需要事务管理的类必须使用interface

事务管理的切面属于(AOP环绕通知)类型的切面。

---------------------------------TODO------------------------------------------------

org.springframework.transaction.interceptor.TransactionAspectSupport类

/**
	 * General delegate for around-advice-based subclasses, delegating to several other template
	 * methods on this class. Able to handle {@link CallbackPreferringPlatformTransactionManager}
	 * as well as regular {@link PlatformTransactionManager} implementations.
	 * @param method the Method being invoked
	 * @param targetClass the target class that we're invoking the method on
	 * @param invocation the callback to use for proceeding with the target invocation
	 * @return the return value of the method, if any
	 * @throws Throwable propagated from the target invocation
	 */
	protected Object invokeWithinTransaction(Method method, Class targetClass, 
						final InvocationCallback invocation)
			throws Throwable {

		// If the transaction attribute is null, the method is non-transactional.
		//这里返回的即是在tx:method中配置的属性值
		//包括propagation, isolation, readonly, timeout, readonly等属性的配置值。
		//如果一个方法没有在tx:method中配置，那么txAttr为null
		final TransactionAttribute txAttr = getTransactionAttributeSource().getTransactionAttribute(method, targetClass);
		final PlatformTransactionManager tm = determineTransactionManager(txAttr);
		final String joinpointIdentification = methodIdentification(method, targetClass);

		if (txAttr == null || !(tm instanceof CallbackPreferringPlatformTransactionManager)) {
			// Standard transaction demarcation with getTransaction and commit/rollback calls.
			//该方法主要就是根据配置来采取合适的事务策略。
			//理解了该方法的调用原理，基本上spring的配置事务的各属性的涵义也就理解了
			TransactionInfo txInfo = createTransactionIfNecessary(tm, txAttr, joinpointIdentification);
			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.proceedWithInvocation();
			}
			catch (Throwable ex) {
				// target invocation exception
				completeTransactionAfterThrowing(txInfo, ex);
				throw ex;
			}
			finally {
				cleanupTransactionInfo(txInfo);
			}
			commitTransactionAfterReturning(txInfo);
			return retVal;
		}

		else {
			// It's a CallbackPreferringPlatformTransactionManager: pass a TransactionCallback in.
			try {
				Object result = ((CallbackPreferringPlatformTransactionManager) tm).execute(txAttr,
						new TransactionCallback