Preface
Many people think that the transaction is very simple, but often encountered some pitfalls in the work (especially when other transaction methods are nested in the transaction method), we don't know the cause of the problem and how to effectively solve it.
This needs to analyze the core source code of Spring, and finally find the cause of the problem and solution ideas down-to-earth.
Annotate transaction operation process
First look at the underlying running process of Spring transactions
Core object relationship
One, transaction configuration related
TransactionManagementConfigurationSelector: When the configuration startup transaction starts (EnableTransactionManagement), import the registered configuration bean.
It includes two configuration blocks, AutoProxyRegistrar and ProxyTransactionManagementConfiguration.
AutoProxyRegistrar: Responsible for the configuration of the relevant properties of the dependency injection transaction and the injection transaction entry class (InfrastructureAdvisorAutoProxyCreator class);
ProxyTransactionManagementConfiguration: Responsible for injecting transaction-related beans, including:
- Transaction Aspect Bean (BeanFactoryTransactionAttributeSourceAdvisor)
- TransactionAttributeSource (transaction configuration attribute bean)
- TransactionInterceptor (transaction interceptor bean);
2. Transaction operation interception related
- 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 call chain. All types of aspects will eventually be packaged into this interface to trigger unified interception;
- TransactionInterceptor: The core business implementation of Spring transaction interceptor, and the AOP call chain will eventually trigger its invoke method;
- TransactionManager: The base interface managed by Spring, distinguished as the upper-layer interface of the sub-interface, and does not define the actual transaction behavior capabilities;
- PlatformTransactionManager: inherit TransactionManager, define transactions and basic behaviors;
- AbstractPlatformTransactionManager: Responsible for realizing the public behavior and general implementation logic in the entire transaction management and running process, it inherits to the PlatformTransactionManager interface;
Source code implementation
Next, let's analyze the source code of Spring transaction, some of the pits and important conclusions will be shared in this process.
One, transaction configuration
TransactionManagementConfigurationSelector.selectImports() is responsible for defining the configuration class added to the spring container
This method is finally parsed in ConfigurationClassParser and finally instantiated into a bean
AutoProxyRegistrar.registerBeanDefinitions() registers InfrastructureAdvisorAutoProxyCreator with beandefinition
ProxyTransactionManagementConfiguration.transactionAdvisor() injects the transaction aspect
Two, transaction creation
One of the actual entry points (and cglib): JdkDynamicAopProxy...invoke()
ReflectiveMethodInvocation.proceed() aspect call chain processing core method
TransactionInterceptor.invoke() triggers transaction interception from here
TransactionAspectSupport.invokeWithinTransaction() realizes the core business of Spring transaction
TransactionAspectSupport.determineTransactionManager() defines the specified transaction manager
For the transaction manager, the DataSourceTransactionManager (a transaction manager that can configure the data source) is used by default, or you can customize the transaction manager and then configure the data source.
createTransactionIfNecessary() creates transaction information TransactionInfo: including data source, transaction connection (ConnectionHolder), transaction status, connection cache, etc.;
DataSourceTransactionManager.doGetTransaction() Get the transaction object: it contains connection packaging and caching
TransactionSynchronizationManager.getResource() connection thread-level cache: to ensure that the current thread gets the only data connection
AbstractPlatformTransactionManager.startTransaction() starts a new transaction
Only when newTransaction is true, spring will do the actual commit or rollback. Here is a very important point. Many pits of nested transactions are not clearly understood here.
DataSourceTransactionManager.doBegin() Open transaction core source code
TransactionSynchronizationManager.bindResource() sets the thread-level binding of the current connection and data source
Three, transaction rollback
For non-programming transactions, the core implementation of Spring transactions is actually the paradigm of using try / catch to wrap transaction commit and rollback, but the packaging in commit and rollback is very particular.
TransactionAspectSupport.completeTransactionAfterThrowing() transaction rollback implementation
In the above screenshot, doSetRollbackOnly() will not actually set the rollback point on the connection, just mark it (the current transaction needs to be rolled back, and this mark will be used when committing)!
Four, transaction commit
AbstractPlatformTransactionManager.commit() transaction actually commits the source code here
CleanupAfterCompletion() recycles the connection or resumes the transaction. This point is intriguing: when the transaction propagation attribute is Require_New, the previous connection will be temporarily suspended, and then a new connection will be created; when the new connection is committed or rolled back, this method is used to restore the previous connection and status! ! ! !
OK transaction is here, I share some sweets about nested sub-transactions based on the source code:
- In the nested transaction process, if there is any exception in the middle, as long as it is not shielded, it will be thrown up, and subsequent code will not be executed;
- As long as the Require_New transaction propagation attribute is set, each Transactional annotation method will be submitted or rolled back separately;
- Nested transactions will create savepoint rollback points in sub-transactions except the first Transactional annotation;
- After setting the savepoint rollback point, all transactions before the current method will be rolled back during rollback; if you only need to roll back the current method, add try{}catch(){//no exception 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;
to sum up
Today's Spring transaction source code is temporarily shared here. The transaction is very simple. The transaction with only one layer is very simple, but when multiple (layer) sub-transactions are nested (and the transaction propagation properties of each sub-transaction may be different) It's a different story.
We need to analyze how each layer of sub-transactions should flow according to the law of the source code! ! So you need to get familiar with the source code of this piece, and if you encounter complex nested transaction analysis reasons, the problem is not big.