- 浏览: 421796 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (318)
- js (20)
- JQuery (2)
- Java (46)
- Oracle (4)
- mysql (21)
- ExtJs (17)
- Excel (2)
- Linux (8)
- Sql (8)
- Jsp (2)
- hibernate (12)
- jbpm (17)
- eclipse (8)
- 名博收藏 (1)
- Junit (2)
- 应用集成 (3)
- web (10)
- jboss (3)
- Rest (3)
- 其它 (7)
- 磁盘分区管理 (1)
- spring (18)
- SSO (4)
- tomcat (4)
- CSS (7)
- MemCached (6)
- EhCache (4)
- weblogic (1)
- apache (6)
- Exception design (1)
- db (1)
- 分析模式 (1)
- jstl (1)
- jsf (0)
- firefox (2)
- MongoDB (4)
- androidpn (1)
- hadoop (1)
- cvs (1)
- 微信公众号 (2)
- 高并发 (4)
- 技术论坛 (1)
- CDN (1)
- JVM (16)
- 加密 (4)
- maven (2)
- jenkins (1)
- hessian (1)
- 大数据处理 (2)
- NIO (0)
- netty (1)
- redis (1)
- git (1)
- Elastic Job (0)
最新评论
-
zgw06629:
或者<pre>aaaabbbbcccc</p ...
javaDoc注释换行 -
ddnzero:
...
StringBuffer换行 -
maosijun:
。。。。
EXT CExt.form.ComboBox选择一次后只剩一个选项 -
ysa198584:
你这有问题,当我的代码出现User.class的时候,反编绎的 ...
java的class文件批量反编译 -
dongj0325:
看到您的博客,很受启发,但还有关于jbpm4.4 timer使 ...
JBPM定时器(Timer)之Repeat属性不能使用变量
其实我的感觉就是事务提交要比事务开始复杂,看事务是否提交我们还是要回到TransactionInterceptor类的invoke方法:
public Object invoke(MethodInvocation invocation) throws Throwable { // Work out the target class: may be null. // 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; }
其中的doFinally(txInfo)那一行很重要,也就是说不管如何,这个doFinally方法都是要被调用的,为什么它这么重要呢,举个例子:
我们还是以propregation_required来举例子吧,假设情况是这样的,AService中有一个方法调用了BService中的,这两个方法都处在事务体之中,他们的传播途径都是required。那么调用开始了,AService的方法首先入方法栈,并创建了TransactionInfo的实例,接着BService的方法入栈,又创建了一个TransactionInfo的实例,而重点要说明的是TransactionInfo是一个自身关联的内部类,第二个方法入栈时,会给新创建的TransactionInfo的实例设置一个属性,就是TransactionInfo对象中的private TransactionInfo oldTransactionInfo;属性,这个属性表明BService方法的创建的TransactionInfo对象是有一个old的transactionInfo对象的,这个oldTransactionInfo对象就是AService方法入栈时创建的TransactionInfo对象,我们还记得在createTransactionIfNecessary方法里有这样一个方法吧:
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) { // 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; } 就是这个bindToThread()方法在作怪: private void bindToThread() { // Expose current TransactionStatus, preserving any existing transactionStatus for // restoration after this transaction is complete. oldTransactionInfo = (TransactionInfo) currentTransactionInfo.get(); currentTransactionInfo.set(this); }
如果当前线程中已经有了一个TransactionInfo,则拿出来放到新建的transactionInfo对象的oldTransactionInfo属性中,然后再把新建的TransactionInfo设置到当前线程中。
这里有一个概念要搞清楚,就是TransactionInfo对象并不是表明事务状态的对象,表明事务状态的对象是TransactionStatus对象,这个对象同样是TransactionInfo的一个属性。
接下来BService中的那个方法返回,那么该它退栈了,它退栈后要做的就是doFinally方法,即把它的oldTransactionInfo设置到当前线程中(这个TransactionInfo对象显然就是AService方法入栈时创建的,怎么现在又要设置到线程中去呢,原因就是BService的方法出栈时并不提交事务,因为BService的传播途径是required,所以要把栈顶的方法所创建transactioninfo给设置到当前线程中),即调用AService的方法时所创建的TransactionInfo对象。那么在AServie的方法出栈时同样会设置TransactionInfo对象的oldTransactionInfo到当前线程,这时候显然oldTransactionInfo是空的,但AService中的方法会提交事务,所以它的oldTransactionInfo也应该是空了。
在这个小插曲之后,接下来就应该是到提交事务了,之前在AService的方法出栈时,我们拿到了它入栈时创建的TransactionInfo对象,这个对象中包含了AService的方法事务状态。即TransactionStatus对象,很显然,太显然了,事务提交中的任何属性都和事务开始时的创建的对象息息相关,这个TransactionStatus对象哪里来的,我们再回头看看createTransactionIfNessary方法吧:
protected TransactionInfo createTransactionIfNecessary(Method method, Class targetClass) {txInfo.newTransactionStatus(this.transactionManager.getTransaction(txAttr));}
再看看transactionManager.getTransaction(txAttr)方法吧:
public final TransactionStatus getTransaction(TransactionDefinition definition) throws TransactionException {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);//注意这里的返回值,返回的就是一个TransactionStatus对象,这个对象表明了一个事务的状态,比如说是否是一个新的事务,事务是否已经结束,等等,这个对象是非常重要的,在事务提交的时候还是会用到它的。}}}
还有一点需要说明的是,AService的方法在执行之前创建的transactionstatus确实是通过这个方法创建的,但是,BService的方法在执行之前创建transactionstatus的方法就与这个不一样了,下面会有详解。
回顾了事务开始时所调用的方法之后,是不是觉得现在对spring如何处理事务越来越清晰了呢。由于这么几个方法的调用,每个方法入栈之前它的事务状态就已经被设置好了。这个事务状态就是为了在方法出栈时被调用而准备的。
让我们再次回到BService中的方法出栈的那个时间段,看看spring都做了些什么,我们知道,后入栈的肯定是先出栈,BService中的方法后入栈,那它肯定要先出栈了,它出栈的时候是要判断是否要提交事务,释放资源的,让我们来看看TransactionInterceptor的invoke的最后那个方法doCommitTransactionAfterReturning:
protected void doCommitTransactionAfterReturning(TransactionInfo txInfo) {if (txInfo != null && txInfo.hasTransaction()) {if (logger.isDebugEnabled()) {logger.debug("Invoking commit for transaction on " + txInfo.joinpointIdentification());}this.transactionManager.commit(txInfo.getTransactionStatus());//瞧:提交事务时用到了表明事务状态的那个TransactionStatus对象了。}}
看这个方法的名字就知道spring是要在业务方法出栈时提交事务,貌似很简单,但是事实是这样的吗?我们接着往下看。
public final void commit(TransactionStatus status) throws TransactionException { DefaultTransactionStatus defStatus = (DefaultTransactionStatus) status; if (defStatus.isCompleted()) { throw new IllegalTransactionStateException( "Transaction is already completed - do not call commit or rollback more than once per transaction"); } if (defStatus.isLocalRollbackOnly()) { if (defStatus.isDebug()) { logger.debug("Transactional code has requested rollback"); } processRollback(defStatus); return; } if (!shouldCommitOnGlobalRollbackOnly() && defStatus.isGlobalRollbackOnly()) { if (defStatus.isDebug()) { logger.debug("Global transaction is marked as rollback-only but transactional code requested commit"); } processRollback(defStatus); throw new UnexpectedRollbackException( "Transaction has been rolled back because it has been marked as rollback-only"); } processCommit(defStatus); }
上面这段代码就是transactionmanager中的commit,但是看上去,它又把自己的职责分配给别人了,从代码里我们看到,如果事务已经结束了就抛异常,如果事务是rollbackonly的,那么就rollback吧,但是按照正常流程,我们还是想来看一下,事务的提交,就是processCommit(status)这个方法吧。
private void processCommit(DefaultTransactionStatus status) throws TransactionException { try { boolean beforeCompletionInvoked = false; try { triggerBeforeCommit(status); triggerBeforeCompletion(status); beforeCompletionInvoked = true; if (status.hasSavepoint()) { if (status.isDebug()) { logger.debug("Releasing transaction savepoint"); } status.releaseHeldSavepoint(); } else if (status.isNewTransaction()) {//这个判断非常重要,下面会详细讲解这个判断的作用 if (status.isDebug()) { logger.debug("Initiating transaction commit"); } boolean globalRollbackOnly = status.isGlobalRollbackOnly(); doCommit(status); // Throw UnexpectedRollbackException if we have a global rollback-only // marker but still didn't get a corresponding exception from commit. ````````````````````` }
我们注意到,在判断一个事务是否是新事务之前还有一个status.hasSavepoint()的判断,我认为这个判断事实上就是嵌套事务的判断,即判断这个事务是否是嵌套事务,如果不是嵌套事务,则再判断它是否是一个新事务,下面这段话就非常重要了,BService的中的方法是先出栈的,也就是说在调用BService之前的创建的那个事务状态对象在这里要先被判断,但是由于在调用BService的方法之前已经创建了一个Transaction和Session(假设我们使用的是hibernate3),这时候在创建第二个TransactionInfo(再强调一下吧,TransactionInfo并不是Transaction,Transaction是真正的事务对象,TransactionInfo只不过是一个辅助类而已,用来记录一系列状态的辅助类)的TransactionStatus的时候就会进入下面这个方法(当然在这之前会判断一下当前线程中是否已经有了一个SessionHolder对象,不清楚SessionHolder作用的同学请看第一篇文章):
private TransactionStatus handleExistingTransaction( TransactionDefinition definition, Object transaction, boolean debugEnabled) throws TransactionException { if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NEVER) { throw new IllegalTransactionStateException( "Transaction propagation 'never' but existing transaction found"); } if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NOT_SUPPORTED) { if (debugEnabled) { logger.debug("Suspending current transaction"); } Object suspendedResources = suspend(transaction); boolean newSynchronization = (this.transactionSynchronization == SYNCHRONIZATION_ALWAYS); return newTransactionStatus( definition, null, false, newSynchronization, debugEnabled, suspendedResources); } if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) { if (debugEnabled) { logger.debug("Suspending current transaction, creating new transaction with name [" + definition.getName() + "]"); } Object suspendedResources = suspend(transaction); doBegin(transaction, definition); boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER); return newTransactionStatus( definition, transaction, true, newSynchronization, debugEnabled, suspendedResources); } if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) { if (!isNestedTransactionAllowed()) { throw new NestedTransactionNotSupportedException( "Transaction manager does not allow nested transactions by default - " + "specify 'nestedTransactionAllowed' property with value 'true'"); } if (debugEnabled) { logger.debug("Creating nested transaction with name [" + definition.getName() + "]"); } if (useSavepointForNestedTransaction()) { // Create savepoint within existing Spring-managed transaction, // through the SavepointManager API implemented by TransactionStatus. // Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization. DefaultTransactionStatus status = newTransactionStatus(definition, transaction, false, false, debugEnabled, null); status.createAndHoldSavepoint(); return status; } else { // Nested transaction through nested begin and commit/rollback calls. // Usually only for JTA: Spring synchronization might get activated here // in case of a pre-existing JTA transaction. doBegin(transaction, definition); boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER); return newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null); } } // Assumably PROPAGATION_SUPPORTS. if (debugEnabled) { logger.debug("Participating in existing transaction"); } boolean newSynchronization = (this.transactionSynchronization != SYNCHRONIZATION_NEVER); return newTransactionStatus(definition, transaction, false, newSynchronization, debugEnabled, null); }
我们看到这个方法其实很明了,就是什么样的传播途径就创建什么样的transactionstatus,这个方法是在事务开始时被调用的,拿到我们之前举的例子中来看下,我们就恍然大悟了,原来,如果之前已经创建过事务,那个这个新建的transactionstauts就不应该是属于一个newTransaction了,所以第3个参数就是false了。
也就是说,在BService的方法出栈要要执行processcommit,但是由于BService的那个TransactionStatus不是一个newTransaction,所以它根本不会触发这个动作:
else if (status.isNewTransaction()) {//这个判断非常重要,下面会详细讲解这个判断的作用if (status.isDebug()) {logger.debug("Initiating transaction commit");}boolean globalRollbackOnly = status.isGlobalRollbackOnly();doCommit(status);}
也就是说在BService的方法出栈后,事务是不会提交的。这完全符合propragation_required的模型。
而在AService的方法出栈后,AService的方法所对应的那个TransactionStatus对象的newTransaction属性是为true的,即它会触发上面这段代码,进行真正的事务提交。让我们回想一下AService方法入栈之前创建TransactionStatus对象的情形吧:
newTransactionStatus(definition, transaction, true, newSynchronization, debugEnabled, null);
看到第3个参数为true没有。
那么事务该提交了吧,事务的提交我想使用过hibernate的人都知道怎么提交了:
txObject.getSessionHolder().getTransaction().commit();
从当前线程中拿到SessionHolder,再拿到开始事务的那个Transaction对象,然后再commit事务。在没有用spring之前,我们经常这么做。
原文链接: http://java.chinaitlab.com/Sprin...
发表评论
-
Spring Security认识
2015-07-28 15:29 589先来谈一谈Acegi的基础知识,Acegi的架构比较复杂,但 ... -
acegi第一个实例
2015-07-28 14:30 385目前acegi(Spring Security)主要是针对简 ... -
Acegi (Spring Security)入门
2015-07-28 13:25 936一、Acegi Security 介绍 1 ... -
Spring JMS MessageListener实现类不能参与事务拦截
2015-06-04 11:29 1372Spring JMS MessageListener实现类不 ... -
spring配置定时器的时间设置
2014-01-10 16:26 544转自:http://blog.csdn.net/zhaoz ... -
Spring跨库事务JOTM
2012-08-18 22:16 660http://sprone.iteye.com/blog/89 ... -
spring+hibernate+jotm分布式事务配置总结
2012-03-10 17:44 869在前段开拓的体系 中 ... -
用Spring集成的JOTM配置分布式事务
2012-03-10 17:38 1227【藏自】http://boy00fly.iteye.com ... -
spring分布式事务实现
2012-03-10 17:27 1069藏自:http://log-cd.iteye.com/blog ... -
主题:解惑:在spring+hibernate中,只读事务是如何被优化的。
2011-08-28 11:00 1248出自:http://www.iteye.com/topic/9 ... -
【收藏】Spring TransactionManager和hibernate吐血经验谈
2011-08-22 20:45 1015http://lsk.iteye.com/blog/17879 ... -
【收藏】Spring事务王国架构
2011-08-20 10:12 645http://book.51cto.com/art/20090 ... -
【转载】TransactionSynchronizationManager理解
2011-08-19 21:25 909出自:http://blog.sina.com.cn/s/bl ... -
【收藏】主题:解惑 spring 嵌套事务
2011-08-18 23:08 697http://www.iteye.com/topic/3590 ... -
主题:Spring源码浅析 -- XML配置文件的载入与解析
2011-07-31 11:06 1073原文:http://www.iteye.com/topic/7 ... -
主题:Spring源代码解析(一):IOC容器
2011-07-31 08:45 776以下内容引自博客:http://jiwenke-spring. ... -
Spring MVC中的IoC容器初始化
2011-06-30 10:16 822http://blog.csdn.net/prince2270 ...
相关推荐
在整个源代码分析中,我们可以看到 Spring 实现声明式事务管理有三个部分: 1. 对在上下文中配置的属性的处理,这里涉及的类是 TransactionAttributeSourceAdvisor,这是一个通知器,用它来对属性值进行处理,属性...
1. **Spring 事务处理**:Spring 提供了声明式事务管理,允许开发者在配置文件中定义事务边界,无需在业务逻辑代码中显式控制事务开始、提交和回滚。它主要基于AOP代理来实现,通过TransactionInterceptor拦截器进行...
使用`@EnableTransactionManagement`注解标记在配置类上,表示启用Spring的声明式事务管理。这个注解会让Spring自动扫描并处理带有`@Transactional`注解的方法。 3. **配置数据源与事务管理器**: 在`...
此外,文章还探讨了AOP的实现和应用,以及如何通过Spring进行声明式事务管理和动态代理。主要内容包括Spring的发展历程、优势、核心结构、IoC高级应用、AOP应用、声明式事务支持等。 适合人群:Java开发工程师,尤其...
而声明式事务管理则通过AOP实现,只需在方法上添加@Transactional注解,Spring就会自动处理事务。在源代码中,`org.springframework.transaction.interceptor`包下的类实现了事务的切面处理。 总的来说,深入分析...
在5.3.x版本中,Spring对声明式事务管理进行了优化,支持更多的事务策略,如PROPAGATION_REQUIRES_NEW用于确保事务隔离。同时,事务回滚规则也更加灵活,可以根据异常类型进行精确控制。 Spring AOP(面向切面编程...
`PlatformTransactionManager`接口定义了事务管理的基本操作,而`@Transactional`注解则实现了声明式事务管理,使得事务控制可以更简单地应用到业务逻辑上。 5. **MVC框架**:Spring MVC是Spring用于构建Web应用的...
Spring提供了编程式和声明式事务管理,声明式事务管理更便于维护和配置,通过`@Transactional`即可实现。 Spring Boot简化了Spring应用程序的启动和配置。`@SpringBootApplication`是Spring Boot的入口点,它包含了...
同时,Spring的事务管理功能支持编程式和声明式事务,确保了数据的一致性。 5. **MVC框架**:Spring MVC是Spring为构建Web应用提供的模块,它实现了Model-View-Controller模式,将业务逻辑、数据和用户界面分离,...
Spring的事务管理可以做到声明式,即通过`@Transactional`注解在方法级别声明事务边界。 在数据访问方面,Spring提供了强大的支持,包括JDBC抽象层、ORM(Object-Relational Mapping)集成,如Hibernate、MyBatis等...
Spring支持编程式事务管理和声明式事务管理。编程式事务管理需要在代码中显式调用开始、提交或回滚事务;而声明式事务管理则通过配置或注解实现,更加简洁。 10. **什么是Spring Data JPA?** Spring Data JPA是...
5. **事务管理**:Spring的PlatformTransactionManager接口和不同的事务策略(如DataSourceTransactionManager)在源码中展示了如何实现声明式事务管理。 三、源码学习价值 1. **设计模式实践**:Spring源码中大量...
2. **面向切面编程(Aspect-Oriented Programming,AOP)**:Spring AOP如何实现切面、通知、连接点等概念,以及如何为应用程序添加声明式事务管理等功能。 3. **Spring MVC**:Spring的Web层是如何工作的,包括...
在`org.springframework.transaction`包中,`PlatformTransactionManager`是事务管理的核心接口,而`@Transactional`注解是声明式事务管理的关键。 6. **Spring表达式语言(Spring Expression Language, SpEL)** ...
2. 事务管理:Spring的声明式事务管理是通过AOP实现的,通过@Transactional注解可以实现事务的自动开启和提交。查看TransactionProxyFactoryBean的源码,可以深入理解这一过程。 五、安全升级 Spring 2.5.6.SEC02是...
3. **声明式事务处理**:Spring通过AOP代理实现了声明式事务管理。开发者可以在服务层方法上添加@Transactional注解,由Spring自动处理事务的开始、提交或回滚。事务的隔离级别、传播行为和超时设置等都可以在配置中...
3. **事务管理**:探究Spring的声明式事务和编程式事务,以及事务传播行为的理解。 4. **MVC框架**:Spring MVC的工作流程,DispatcherServlet、Controller、ModelAndView等组件的详细运作。 5. **数据访问**:...
7. **spring高级源码笔记.pdf**:这可能包含了对Spring框架源代码的深入解读,有助于理解Spring的工作原理,对于想要深入了解Spring的开发者非常有价值。 8. **廖雪峰 Java教程.pdf**:廖雪峰的Java教程是初学者的...