原文地址:http://blog.jhades.org/how-does-spring-transactional-really-work/

In this post we will do a deep dive into Spring transaction management. We will go over on how does @Transactional really works under the hood. Other upcoming posts will include:

  • how to use features like propagation and isolation
  • what are the main pitfalls and how to avoid them

JPA and Transaction Management

It's important to notice that JPA on itself does not provide any type of declarative transaction management. When using JPA outside of a dependency injection container, transactions need to be handled programatically by the developer:

1
2
3
4
5
6
7
8
9
10
11
12
UserTransaction utx = entityManager.getTransaction();
 
try {
    utx.begin();
 
    businessLogic();
 
    utx.commit();
} catch(Exception ex) {
    utx.rollback();
    throw ex;
}

This way of managing transactions makes the scope of the transaction very clear in the code, but it has several disavantages:

  • it's repetitive and error prone
  • any error can have a very high impact
  • errors are hard to debug and reproduce
  • this decreases the readability of the code base
  • What if this method calls another transactional method?

Using Spring @Transactional

With Spring @Transactional, the above code gets reduced to simply this:

1
2
3
4
@Transactional
public void businessLogic() {
    ... use entity manager inside a transaction ...
}

This is much more convenient and readable, and is currently the recommended way to handle transactions in Spring.

By using @Transactional, many important aspects such as transaction propagation are handled automatically. In this case if another transactional method is called by businessLogic(), that method will have the option of joining the ongoing transaction.

One potential downside is that this powerful mechanism hides what is going on under the hood, making it hard to debug when things don't work.

What does @Transactional mean?

One of the key points about @Transactional is that there are two separate concepts to consider, each with it's own scope and life cycle:

  • the persistence context
  • the database transaction

The transactional annotation itself defines the scope of a single database transaction. The database transaction happens inside the scope of apersistence context.

The persistence context is in JPA the EntityManager, implemented internally using an Hibernate Session (when using Hibernate as the persistence provider).

The persistence context is just a synchronizer object that tracks the state of a limited set of Java objects and makes sure that changes on those objects are eventually persisted back into the database.

This is a very different notion than the one of a database transaction. One Entity Manager can be used across several database transactions, and it actually often is.

When does an EntityManager span multiple database transactions?

The most frequent case is when the application is using the Open Session In View pattern to deal with lazy initialization exceptions, see this previous blog post for it's pros and cons.

In such case the queries that run in the view layer are in separate database transactions than the one used for the business logic, but they are made via the same entity manager.

Another case is when the persistence context is marked by the developer as PersistenceContextType.EXTENDED, which means that it can survive multiple requests.

What defines the EntityManager vs Transaction relation?

This is actually a choice of the application developer, but the most frequent way to use the JPA Entity Manager is with the 
"Entity Manager per application transaction" pattern. This is the most common way to inject an entity manager:

1
2
@PersistenceContext
private EntityManager em;

Here we are by default in "Entity Manager per transaction" mode. In this mode, if we use this Entity Manager inside a @Transactional method, then the method will run in a single database transaction.

How does @PersistenceContext work?

One question that comes to mind is, how can @PersistenceContext inject an entity manager only once at container startup time, given that entity managers are so short lived, and that there are usually multiple per request.

The answer is that it can't: EntityManager is an interface, and what gets injected in the spring bean is not the entity manager itself but a context aware proxy that will delegate to a concrete entity manager at runtime.

Usually the concrete class used for the proxy is 
SharedEntityManagerInvocationHandler, this can be confirmed with the help a debugger.

How does @Transactional work then?

The persistence context proxy that implements EntityManager is not the only component needed for making declarative transaction management work. Actually three separate components are needed:

  • The EntityManager Proxy itself
  • The Transactional Aspect
  • The Transaction Manager

Let's go over each one and see how they interact.

The Transactional Aspect

The Transactional Aspect is an 'around' aspect that gets called both before and after the annotated business method. The concrete class for implementing the aspect is TransactionInterceptor.

The Transactional Aspect has two main responsibilities:

  • At the 'before' moment, the aspect provides a hook point for determining if the business method about to be called should run in the scope of an ongoing database transaction, or if a new separate transaction should be started.

  • At the 'after' moment, the aspect needs to decide if the transaction should be committed, rolled back or left running.

At the 'before' moment the Transactional Aspect itself does not contain any decision logic, the decision to start a new transaction if needed is delegated to the Transaction Manager.

The Transaction Manager

The transaction manager needs to provide an answer to two questions:

  • should a new Entity Manager be created?
  • should a new database transaction be started?

This needs to be decided at the moment the Transactional Aspect 'before' logic is called. The transaction manager will decide based on:

  • the fact that one transaction is already ongoing or not
  • the propagation attribute of the transactional method (for exampleREQUIRES_NEW always starts a new transaction)

If the transaction manager decides to create a new transaction, then it will:

  • create a new entity manager
  • bind the entity manager to the current thread
  • grab a connection from the DB connection pool
  • bind the connection to the current thread

The entity manager and the connection are both bound to the current thread using ThreadLocal variables.

They are stored in the thread while the transaction is running, and it's up to the Transaction Manager to clean them up when no longer needed.

Any parts of the program that need the current entity manager or connection can retrieve them from the thread. One program component that does exactly that is the EntityManager proxy.

The EntityManager proxy

The EntityManager proxy (that we have introduced before) is the last piece of the puzzle. When the business method calls for example 
entityManager.persist(), this call is not invoking the entity manager directly.

Instead the business method calls the proxy, which retrieves the current entity manager from the thread, where the Transaction Manager put it.

Knowing now what are the moving parts of the @Transactionalmechanism, let's go over the usual Spring configuration needed to make this work.

Putting It All Together

Let's go over how to setup the three components needed to make the transactional annotation work correctly. We start by defining the entity manager factory.

This will allow the injection of Entity Manager proxies via the persistence context annotation:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Configuration
public class EntityManagerFactoriesConfiguration {
    @Autowired
    private DataSource dataSource;
 
    @Bean(name = "entityManagerFactory")
    public LocalContainerEntityManagerFactoryBean emf() {
        LocalContainerEntityManagerFactoryBean emf = ...
        emf.setDataSource(dataSource);
        emf.setPackagesToScan(
            new String[] {"your.package"});
        emf.setJpaVendorAdapter(
            new HibernateJpaVendorAdapter());
        return emf;
    }
}

The next step is to configure the Transaction Manager and to apply the Transactional Aspect in @Transactional annotated classes:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
@Configuration
@EnableTransactionManagement
public class TransactionManagersConfig {
    @Autowired
    EntityManagerFactory emf;
    @Autowired
    private DataSource dataSource;
 
    @Bean(name = "transactionManager")
    public PlatformTransactionManager transactionManager() {
        JpaTransactionManager tm =
            new JpaTransactionManager();
            tm.setEntityManagerFactory(emf);
            tm.setDataSource(dataSource);
        return tm;
    }
}

The annotation @EnableTransactionManagement tells Spring that classes with the @Transactional annotation should be wrapped with the Transactional Aspect. With this the @Transactional is now ready to be used.

Conclusion

The Spring declarative transaction management mechanism is very powerful, but it can be misused or wrongly configured easily.

Understanding how it works internally is helpful when troubleshooting situations when the mechanism is not at all working or is working in an unexpected way.

The most important thing to bear in mind is that there are really two concepts to take into account: the database transaction and the persistence context, each with it's own not readily apparent life cycle.

A future post will go over the most frequent pitfalls of the transactional annotation and how to avoid them.

How does Spring @Transactional Really Work?--转的更多相关文章

  1. 数据库事务中的隔离级别和锁+spring Transactional注解

    数据库事务中的隔离级别和锁 数据库事务在后端开发中占非常重要的地位,如何确保数据读取的正确性.安全性也是我们需要研究的问题.ACID首先总结一下数据库事务正确执行的四个要素(ACID): 原子性(At ...

  2. Spring @Transactional使用的示例

    Spring @Transactional使用的示例: 参考: http://blog.csdn.net/seng3018/article/details/6690527 http://blog.si ...

  3. Spring @Transactional 使用

    Spring @Transactional是Spring提供的一个声明式事务,对代码的侵入性比较小,只需考虑业务逻辑,不需要把事务和业务搞混在一起. @Transactional 可以注解在inter ...

  4. Java:Spring @Transactional工作原理

    本文将深入研究Spring的事务管理.主要介绍@Transactional在底层是如何工作的.之后的文章将介绍: propagation(事务传播)和isolation(隔离性)等属性的使用 事务使用 ...

  5. spring @Transactional 事务注解

    @Transactional(propagation = Propagation.REQUIRED, isolation = Isolation.SERIALIZABLE, rollbackFor = ...

  6. Spring @Transactional (一)

    Spring @Transactional (一) 博客分类: JAVA SpringJPAJDBCUPSQL  Spring事务的传播行为 在service类前加上@Transactional,声明 ...

  7. [转]数据库事务中的隔离级别和锁+spring Transactional注解

    数据库事务中的隔离级别和锁 数据库事务在后端开发中占非常重要的地位,如何确保数据读取的正确性.安全性也是我们需要研究的问题.ACID首先总结一下数据库事务正确执行的四个要素(ACID): 原子性(At ...

  8. 25.Spring @Transactional工作原理

    转自:http://www.importnew.com/12300.html 本文将深入研究Spring的事务管理.主要介绍@Transactional在底层是如何工作的.之后的文章将介绍: prop ...

  9. Spring @Transactional ——事务回滚

    工作原理运行配置@Transactional注解的测试类的时候,具体会发生如下步骤1)事务开始时,通过AOP机制,生成一个代理connection对象,并将其放入DataSource实例的某个与Dat ...

随机推荐

  1. Android—LayoutInflater学习笔记

    LayoutInflater的的主要用处:使用LayoutInflater来载入界面,类似于findViewById()在Activity中加载Widget组件一样.区别在于与LayoutInflat ...

  2. PAT/字符串处理习题集(一)

    B1006. 换个格式输出整数 (15) Description: 让我们用字母B来表示"百".字母S表示"十",用"12...n"来表示个 ...

  3. MVC中调用Public_Class时,VS2012老提示:当前上下文中不存在名称“Json”的解决方法

    TMD,老TMD困扰我,每次新建MVC项目后就提示这个,原因在此: public class Public_Class   <==此处应为:Public_Class : Controller { ...

  4. RCP:【转载】插件无法启动的解决方案

    有空了再翻译吧…… Table 2. Run configuration problems Problem Investigate During start you get error message ...

  5. RCP:为指定的导航器添加上下文菜单

    可以参考Eclipse的Help->Help Content下的: Platform Plug-in Developer Guide > Programmer's Guide > P ...

  6. 【腾讯Bugly干货分享】微信读书iOS性能优化

    本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/578c93ca9644bd524bfcabe8 “8小时内拼工作,8小时外拼成长 ...

  7. Java多线程系列--“JUC锁”05之 非公平锁

    概要 前面两章分析了"公平锁的获取和释放机制",这一章开始对“非公平锁”的获取锁/释放锁的过程进行分析.内容包括:参考代码获取非公平锁(基于JDK1.7.0_40)释放非公平锁(基 ...

  8. JavaScript思维导图—正则表达式

    JavaScript思维导图-来自@王子墨http://julying.com/blog/the-features-of-javascript-language-summary-maps/

  9. python property

    python property 在2.6版本中,添加了一种新的类成员函数的访问方式--property. 原型 class property([fget[, fset[, fdel[, doc]]]] ...

  10. [安卓] 15、用NFC解锁手机并自动打开应用

    最近接到一个项目:将手机放到一个带有NFC卡的底座上手机会自动解锁,然后打开相应的应用 本人用:杭州公交通用卡做为NFC卡+Coolpad手机进行试验 效果如下: 1.手机本身带有图案锁,输对图案才能 ...