Shulou(Shulou.com)06/03 Report--

1. Several ways of Spring transaction management:

Spring transactions can be divided into two categories in terms of how they are used:

1. Declarative type

Declarative transaction Management based on TransactionProxyFactoryBean

Transaction management based on and namespace

Declarative transaction Management based on @ Transactional

two。 Programming

Programmatic transaction Management based on transaction Manager API

Programmatic transaction Management based on TransactionTemplate

At present, most projects use the latter two declarative types:

Declarative transaction management based on and namespaces can take full advantage of the strong support of pointcut expressions and make managing transactions more flexible.

II. Spring transaction implementation mechanism

Next, let's take a closer look at the source code of the Spring transaction to understand how it works. Let's start with the parsing class of the tag:

@ Override public void init () {registerBeanDefinitionParser ("advice", new TxAdviceBeanDefinitionParser ()); registerBeanDefinitionParser ("annotation-driven", new AnnotationDrivenBeanDefinitionParser ()); registerBeanDefinitionParser ("jta-transaction-manager", new JtaTransactionManagerBeanDefinitionParser ());} class TxAdviceBeanDefinitionParser extends AbstractSingleBeanDefinitionParser {@ Override protected Class getBeanClass (Element element) {return TransactionInterceptor.class;}}

From this, we can see the core implementation class TransactionInterceptor of Spring transaction and its parent class TransactionAspectSupport, which realizes transaction opening, database operation, transaction commit, rollback and so on. We can also debug breakpoints in this method if we want to determine whether we are in a transaction during development.

TransactionInterceptor:

Public Object invoke (final MethodInvocation invocation) throws Throwable {Class targetClass = (invocation.getThis ()! = null? AopUtils.getTargetClass (invocation.getThis ()): null); / / Adapt to TransactionAspectSupport's invokeWithinTransaction... Return invokeWithinTransaction (invocation.getMethod (), targetClass, new InvocationCallback () {@ Override public Object proceedWithInvocation () throws Throwable {return invocation.proceed ();}});}

TransactionAspectSupport

Protected Object invokeWithinTransaction (Method method, Class targetClass, final InvocationCallback invocation) throws Throwable {/ / If the transaction attribute is null, the method is non-transactional. Final TransactionAttribute txAttr = getTransactionAttributeSource (). GetTransactionAttribute (method, targetClass); final PlatformTransactionManager tm = determineTransactionManager (txAttr); final String joinpointIdentification = methodIdentification (method, targetClass, txAttr); if (txAttr = = null | |! (tm instanceof CallbackPreferringPlatformTransactionManager)) {/ / Standard transaction demarcation with getTransaction and commit/rollback calls. 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 }}

At this point, we understand the entire invocation process of the transaction, but there is another important mechanism that has not been analyzed, that is, the Spring transaction controls the currently acquired database connection for different propagation levels. Next, let's take a look at the utility classes DataSourceUtils,JdbcTemplate and Mybatis-Spring that are used by Spring to obtain connections. Connection is also obtained through this class.

Public abstract class DataSourceUtils {... Public static Connection getConnection (DataSource dataSource) throws CannotGetJdbcConnectionException {try {return doGetConnection (dataSource);} catch (SQLException ex) {throw new CannotGetJdbcConnectionException ("Could not get JDBC Connection", ex);}} public static Connection doGetConnection (DataSource dataSource) throws SQLException {Assert.notNull (dataSource, "No DataSource specified"); ConnectionHolder conHolder = (ConnectionHolder) TransactionSynchronizationManager.getResource (dataSource) If (conHolder! = null & & (conHolder.hasConnection () | | conHolder.isSynchronizedWithTransaction () {conHolder.requested (); if (! conHolder.hasConnection ()) {logger.debug ("Fetching resumed JDBC Connection from DataSource"); conHolder.setConnection (dataSource.getConnection ());} return conHolder.getConnection () }... }

TransactionSynchronizationManager is also a core class of transaction synchronization management, which implements the function of transaction synchronization management, including recording the current connection holding connection holder.

TransactionSynchronizationManager

Private static final ThreadLocal resources = new NamedThreadLocal ("Transactional resources"); … Public static Object getResource (Object key) {Object actualKey = TransactionSynchronizationUtils.unwrapResourceIfNecessary (key); Object value = doGetResource (actualKey); if (value! = null & & logger.isTraceEnabled ()) {logger.trace ("Retrieved value [" + value + "] for key [" + actualKey + "] bound to thread [" + Thread.currentThread (). GetName () + "]) } return value;} / * * Actually check the value of the resource that is bound for the given key. * / private static Object doGetResource (Object actualKey) {Map map = resources.get (); if (map = = null) {return null;} Object value = map.get (actualKey); / / Transparently remove ResourceHolder that was marked as void... If (value instanceof ResourceHolder & ((ResourceHolder) value) .isVoid () {map.remove (actualKey); / / Remove entire ThreadLocal if empty... If (map.isEmpty ()) {resources.remove ();} value = null;} return value;}

In the transaction manager class AbstractPlatformTransactionManager, when getTransaction acquires a transaction, it handles different transaction propagation behaviors, such as the current transaction, but when the calling method transaction propagation level is REQUIRES_NEW or PROPAGATION_NOT_SUPPORTED, it suspends and resumes the current transaction, thus ensuring that the current database operation obtains the correct Connection.

Specifically, the suspended transaction will be resumed at the end of the subtransaction commit, and TransactionSynchronizationManager will be called again when the transaction is resumed. The connection holder before bindResource is set, so that the reacquired connection is the restored database connection, and only one connection can be currently activated by TransactionSynchronizationManager.

AbstractPlatformTransactionManager

Private TransactionStatus handleExistingTransaction (TransactionDefinition definition, Object transaction, boolean debugEnabled) throws TransactionException {if (definition.getPropagationBehavior () = = TransactionDefinition.PROPAGATION_REQUIRES_NEW) {if (debugEnabled) {logger.debug ("Suspending current transaction, creating new transaction with name [" + definition.getName () + "]");} SuspendedResourcesHolder suspendsuspendedResources = suspend (transaction) Try {boolean newSynchronization = (getTransactionSynchronization ()! = SYNCHRONIZATION_NEVER); DefaultTransactionStatus status = newTransactionStatus (definition, transaction, true, newSynchronization, debugEnabled, suspendedResources); doBegin (transaction, definition); prepareSynchronization (status, definition); return status } catch (RuntimeException beginEx) {resumeAfterBeginException (transaction, suspendedResources, beginEx); throw beginEx;} catch (Error beginErr) {resumeAfterBeginException (transaction, suspendedResources, beginErr); throw beginErr Cleanup after completion, clearing synchronization if necessary, * and invoking doCleanupAfterCompletion. * @ param status object representing the transaction * @ see # doCleanupAfterCompletion * / private void cleanupAfterCompletion (DefaultTransactionStatus status) {status.setCompleted (); if (status.isNewSynchronization ()) {TransactionSynchronizationManager.clear ();} if (status.isNewTransaction ()) {doCleanupAfterCompletion (status.getTransaction ()) } if (status.getSuspendedResources ()! = null) {if (status.isDebug ()) {logger.debug ("Resuming suspended transaction after completion of inner transaction");} resume (status.getTransaction (), (SuspendedResourcesHolder) status.getSuspendedResources ());}}

The transaction of Spring takes effect through an Advice (TransactionInterceptor) in the AOP agent class, and the propagation level defines how the transaction and child transactions acquire connections, commit transactions, and roll back.

AOP (Aspect Oriented Programming), that is, aspect-oriented programming. The implementation of Spring AOP technology is actually a proxy class, which can be divided into two categories: static proxy and dynamic proxy, in which static proxy is compiled using commands provided by the AOP framework, so that the AOP proxy class can be generated in the compilation phase, so it is also called compile-time enhancement; (AspectJ) Dynamic proxies generate AOP dynamic proxy classes in memory "temporarily" at run time with the help of dictation class libraries, so they are also called runtime enhancements. Where java is the dynamic proxy mode (JDK+CGLIB) used.

JDK dynamic proxy JDK dynamic proxy mainly involves two classes in the java.lang.reflect package: Proxy and InvocationHandler. InvocationHandler is an interface that defines crosscutting logic by implementing it, and invokes the code of the target class through reflection mechanism, dynamically compiling crosscutting logic and business logic together. Proxy uses InvocationHandler to dynamically create an instance that conforms to a certain interface and generate the proxy object of the target class.

CGLIB dynamic proxy CGLIB, whose full name is Code Generation Library, is a powerful high-performance, high-quality code generation class library that can extend the Java class and implement Java interface at run time. CGLIB encapsulates asm and can dynamically generate new class at run time. Compared with JDK dynamic proxies, JDK has a limitation that proxy instances can only be created for interfaces, while for classes that do not define business methods through interfaces, dynamic proxies can be created through CGLIB.

CGLIB creates the agent slowly, but runs very fast after it is created, while the JDK dynamic agent is just the opposite. If you constantly use CGLIB to create agents at run time, the performance of the system will be greatly reduced. Therefore, if there is an interface, Spring uses JDK dynamic proxy by default. The source code is as follows:

Public class DefaultAopProxyFactory implements AopProxyFactory, Serializable {@ Override public AopProxy createAopProxy (AdvisedSupport config) throws AopConfigException {if (config.isOptimize () | | config.isProxyTargetClass () | | hasNoUserSuppliedProxyInterfaces (config)) {Class targetClass = config.getTargetClass () If (targetClass = = null) {throw new AopConfigException ("TargetSource cannot determine target class:" + "Either an interface or a target is required for proxy creation.");} if (targetClass.isInterface () | | Proxy.isProxyClass (targetClass)) {return new JdkDynamicAopProxy (config) } return new ObjenesisCGLIBAopProxy (config);} else {return new JdkDynamicAopProxy (config);}

After understanding the two characteristics of Spring proxy, we also know some considerations when doing transaction aspect configuration. For example, when a JDK proxy method must be a public,CGLIB proxy, it must be public, protected, and the class cannot be final. In dependency injection, if the attribute type is defined as an implementation class, JDK Agent will report the following injection exception:

Org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'com.wwb.test.TxTestAop': Unsatisfied dependency expressed through field' service'; nested exception is org.springframework.beans.factory.BeanNotOfRequiredTypeException: Bean named 'stockService' is expected to be of type' com.wwb.service.StockProcessServiceImpl' but was actually of type 'com.sun.proxy.$Proxy14'

However, if it is modified to a CGLIB proxy, it will be injected successfully, so if there is an interface, it is recommended that this class property be defined as an interface when injecting. In addition, transaction pointcuts are configured when both the implementation class and the interface can take effect, but it is recommended to add them to the implementation class.

Detailed introduction of Spring AOP on the official website: https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html%23aop

III. Those holes in Spring affairs

From the previous chapter, I'm sure you've mastered how and how spring transactions are used, but be careful, because you can fall into a hole if you're not careful. First of all, let's look at the first pit:

3.1 transaction does not take effect

Test code, transaction AOP configuration:

Public class StockProcessServiceImpl implements IStockProcessService {@ Autowired private IAccountDao accountDao; @ Autowired private IStockDao stockDao; @ Override public void openAccount (String aname, double money) {accountDao.insertAccount (aname, money);} @ Override public void openStock (String sname, int amount) {stockDao.insertStock (sname, amount) } @ Override public void openStockInAnotherDb (String sname, int amount) {stockDao.insertStock (sname, amount);}} public void insertAccount (String aname, double money) {String sql = "insert into account (aname, balance) values (?)"; this.getJdbcTemplate (). Update (sql, aname, money); DbUtils.printDBConnectionInfo ("insertAccount", getDataSource ()) } public void insertStock (String sname, int amount) {String sql = "insert into stock (sname, count) values"; this.getJdbcTemplate (). Update (sql, sname, amount); DbUtils.printDBConnectionInfo ("insertStock", getDataSource ());} public static void printDBConnectionInfo (String methodName,DataSource ds) {Connection connection = DataSourceUtils.getConnection (ds) System.out.println (methodName+ "connection hashcode=" + connection.hashCode ());} / / call similar methods, peripheral configuration transaction public void openTx (String aname, double money) {openAccount (aname,money); openStock (aname,11);}

1. Run the output:

InsertAccount connection hashcode=319558327

InsertStock connection hashcode=319558327

/ / call similar methods with no transaction public void openWithoutTx (String aname, double money) {openAccount (aname,money); openStock (aname,11);}

two。 Run the output:

InsertAccount connection hashcode=1333810223

InsertStock connection hashcode=1623009085

/ / obtain the agent @ Override public void openWithMultiTx (String aname, double money) {openAccount (aname,money); openStockInAnotherDb (aname, 11) through the AopContext.currentProxy () method; / / the propagation level is REQUIRES_NEW}

3. Run the output:

InsertAccount connection hashcode=303240439

InsertStock connection hashcode=303240439

We can see that the test methods of 2 and 3 are not the same as our transaction expectations. conclusion: if the calling method is not configured with a transaction, this kind of method is called directly, the transaction does not take effect!

The reason is that the transaction of Spring is essentially a proxy class, and when the method of this class is called directly, the object itself is not a proxy woven into the transaction, so the transaction aspect does not take effect. For more information, see # Spring transaction implementation mechanism # section.

Spring also provides a way to determine whether it is a proxy:

Public static void printProxyInfo (Object bean) {System.out.println ("isAopProxy" + AopUtils.isAopProxy (bean)); System.out.println ("isCGLIBProxy=" + AopUtils.isCGLIBProxy (bean)); System.out.println ("isJdkProxy=" + AopUtils.isJdkDynamicProxy (bean));}

So how do you change it to a proxy class call? The most direct idea is to inject yourself, the code is as follows:

@ Autowired private IStockProcessService stockProcessService; / / injects its own class, circular dependency, and public void openTx (String aname, double money) {stockProcessService.openAccount (aname,money); stockProcessService.openStockInAnotherDb (aname,11);}

Of course, Spring provides a method to get the current proxy: the code is as follows:

In addition, Spring obtains the database connection in the transaction through the thread variable of the TransactionSynchronizationManager class, so if it is multithreaded call or bypass Spring to obtain the database connection, it will cause the Spring transaction configuration to fail.

Finally, the scenario where the configuration of Spring transaction fails:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Transaction aspect is not configured correctly

This kind of method call

Multithreaded call

Bypass Spring to get database connection

Next, let's take a look at another hole in Spring's transaction:

3.2 transactions are not rolled back

Test the code:

@ Test public void testBuyStock () {try {service.openAccount ("dcbs", 10000); service.buyStock ("dcbs", 2000, "dap", 5);} catch (StockException e) {e.printStackTrace ();} double accountBalance = service.queryAccountBalance ("dcbs"); System.out.println ("account balance is" + accountBalance);}

Output result:

InsertAccount connection hashcode=656479172

UpdateAccount connection hashcode=517355658

Account balance is 8000.0

The application throws an exception, but accountDao.updateAccount commits it. To investigate the reason, look directly at the Spring source code:

TransactionAspectSupport

Protected void completeTransactionAfterThrowing (TransactionInfo txInfo, Throwable ex) {if (txInfo! = null & & txInfo.hasTransaction ()) {if (logger.isTraceEnabled ()) {logger.trace ("Completing transaction for [" + txInfo.getJoinpointIdentification () + "] after exception:" + ex) } if (txInfo.transactionAttribute.rollbackOn (ex)) {try {txInfo.getTransactionManager () .rollback (txInfo.getTransactionStatus ());} catch (TransactionSystemException ex2) {logger.error ("Application exception overridden by rollback exception", ex) Ex2.initApplicationException (ex); throw ex2;}... } public class DefaultTransactionAttribute extends DefaultTransactionDefinition implements TransactionAttribute {@ Override public boolean rollbackOn (Throwable ex) {return (ex instanceof RuntimeException | | ex instanceof Error);}... }

As can be seen from the code, the Spring transaction rolls back only RuntimeException and Error by default. If the application needs to roll back the specified exception class, you can configure the rollback-for= property, for example:

The reason why the transaction is not rolled back:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Transaction configuration aspect does not take effect

Catch the exception in the application method

The exception thrown is not a run-time exception (for example, IOException)

The rollback-for property is not configured correctly

Next, let's take a look at the third pit of Spring transactions:

3.3 transaction timeout does not take effect

Test the code:

@ Override public void openAccountForLongTime (String aname, double money) {accountDao.insertAccount (aname, money); try {Thread.sleep (5000L); / / timeout after database operation} catch (InterruptedException e) {e.printStackTrace ();}} @ Test public void testTimeout () {service.openAccountForLongTime ("dcbs", 10000);}

Normal operation, transaction timeout does not take effect

Public void openAccountForLongTime (String aname, double money) {try {Thread.sleep (5000L); / / timeout before database operation} catch (InterruptedException e) {e.printStackTrace ();} accountDao.insertAccount (aname, money);}

A transaction timeout exception is thrown, and the timeout takes effect

Org.springframework.transaction.TransactionTimedOutException: Transaction timed out: deadline was Fri Nov 23 17:03:02 CST 2018

At org.springframework.transaction.support.ResourceHolderSupport.checkTransactionTimeout (ResourceHolderSupport.java:141)

...

Look at the Spring transaction timeout judgment mechanism through the source code:

ResourceHolderSupport

/ * Return the time to live for this object in milliseconds. * @ return number of millseconds until expiration * @ throws TransactionTimedOutException if the deadline has already been reached * / public long getTimeToLiveInMillis () throws TransactionTimedOutException {if (this.deadline = = null) {throw new IllegalStateException ("No timeout specified for this resource holder");} long timeToLive = this.deadline.getTime ()-System.currentTimeMillis (); checkTransactionTimeout (timeToLive

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.