I entered Dachang as a senior Java development engineer by self-study. Wechat search [IT elder brother] follows this self-taught programmer.

This is a list of the latest Java interview questions for 2020, covering all areas of Java technology.

preface

Many people think that transaction is very simple, but often in the work of some transaction pit (especially in the transaction method nested with other transaction methods used together), we do not know the cause of the problem and how to effectively solve.

It is necessary to analyze the core source code of Spring and finally find the cause and solution of the problem.

Annotate the transaction running process

Let’s start with the underlying running flow of Spring transactions


Core object relationship

First, transaction configuration is relevant

TransactionManagementConfigurationSelector: configuration start transaction start (EnableTransactionManagement), import registration the configuration of the bean.

It includes AutoProxyRegistrar and ProxyTransactionManagementConfiguration configuration block.

AutoProxyRegistrar: dependency injection related properties for configuration and injection affairs entrance class (InfrastructureAdvisorAutoProxyCreator class);

Bean ProxyTransactionManagementConfiguration: for injection affairs related, including:

  • Affairs section Bean (BeanFactoryTransactionAttributeSourceAdvisor)

  • TransactionAttributeSource (transaction configuration properties beans)

  • TransactionInterceptor (TransactionInterceptor bean);

Second, transaction running interception

  • AopProxy: The base interface of Spring AOP dynamic Proxy, responsible for defining the basic behavior of Proxy;

  • MethodInterceptor: The internal core interface of the interceptor in the Spring AOP invocation chain, into which all types of facets are ultimately wrapped to trigger a unified interception;

  • TransactionInterceptor: the core business implementation of Spring’s TransactionInterceptor, whose invoke method is eventually triggered by the AOP invocation chain;

  • TransactionManager: a spring-managed base interface, distinguished as a subinterface, that does not define the actual transactional behavior capabilities;

  • TransactionManager PlatformTransactionManager: inheritance, definition and basic behavior;

  • AbstractPlatformTransactionManager: responsible for implementing the public behavior of the whole process of transaction management and operation and general implementation logic, it inherits to the PlatformTransactionManager interface;

The source code to achieve

Let’s take a look at the source code for Spring transactions in pieces, with some potholes and important conclusions shared in the process.

Transaction configuration

TransactionManagementConfigurationSelector. SelectImports () is responsible for defining external to join the spring container configuration class


This method is eventually parsed in ConfigurationClassParser and eventually instantiated as a bean



AutoProxyRegistrar. RegisterBeanDefinitions InfrastructureAdvisorAutoProxyCreator registered beandefinition ()



ProxyTransactionManagementConfiguration. TransactionAdvisor injected affairs section ()



Transaction creation

One of the actual run entries (and cglib) : JdkDynamicAopProxy.. invoke()



ReflectiveMethodInvocation. Proceed () invocation chain processing core cross section method


TransactionInterceptor. Invoke trigger transaction interception () from here


TransactionAspectSupport. InvokeWithinTransaction () Spring transaction’s core business


TransactionAspectSupport. DetermineTransactionManager () definition specifies the transaction manager


For the transaction manager, use the default DataSourceTransactionManager (configurable data transaction manager), can also be customized transaction manager, then configure the data source.

TransactionInfo createTransactionIfNecessary () create a transaction information, including data source, transaction connection (ConnectionHolder), the state of affairs, connection caching, etc;

DataSourceTransactionManager. DoGetTransaction () to obtain the transaction object: package and cache containing connection


TransactionSynchronizationManager. GetResource () connection thread level cache: get the only data connections ensure that the current thread



AbstractPlatformTransactionManager. StartTransaction () to open a new transaction

It is important to note that Spring does the actual commit or rollback only if newTransaction is true. Many nested transaction pits are not clearly understood here.

Core source DataSourceTransactionManager. DoBegin () open transactions

TransactionSynchronizationManager. BindResource () sets the current connection thread binding and data sources


Transaction rollback

For non-programmatic transactions, the core implementation of Spring transactions is nothing more than a try/catch wrapped transaction commit and rollback paradigm, but there is a lot of wrapping inside commit and rollback.

TransactionAspectSupport.com pleteTransactionAfterThrowing transaction rollback () implementation



In the screenshot above, doSetRollbackOnly() does not actually set the rollback point on the connection, just flags it (the current transaction needs to be rolled back, and this flag will be used at commit time)!

Iv. Transaction submission

AbstractPlatformTransactionManager.com MIT () the transaction actually commit the source code here




CleanupAfterCompletion () reclaims the connection or restores the transaction, which is interesting: when the transaction propagation property is Require_New, the previous connection is temporarily suspended and a new connection is created; This method is used to restore the previous connection and state ！！！！ when a new connection is committed or rolled back




OK transaction to this point, I share some of the source code about nested sub transactions sweet:

  • Nested transaction process, any exception in the middle, as long as it is not shielded, will be thrown, will not execute the subsequent code;

  • Each Transactional annotation method is committed or rolled back internally as long as the Require_New transaction propagation property is set.

  • Nested transactions create savePoint rollback points in sub-transactions other than the first Transactional annotation;

  • When the savePoint rollback point is set, all transactions prior to the current method are rolled back. If only the current method needs to be rolled back, add try{}catch(){// no exception thrown} to the outermost transaction method;

  • The object of each transaction is different, the transaction state may be different, but the connection may be the same;

conclusion

The source code for Spring transactions is shared here for the time being. A transaction is a simple one-level transaction, but it is a different matter when there are multiple (layer) nested sub-transactions (and the transaction propagation properties of each sub-transaction may be different).

Need we according to the law of the source code to analyze each level of sub transaction how the flow!! So need to be familiar with this piece of source code, encounter complex nested transaction analysis reasons, that problem is not big.

wavebeed


This article is formatted using MDNICE