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

This article focuses on "when Spring declarative transactions will fail", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "under what circumstances will Spring declarative transactions fail?"

Programmatic transaction

There are two ways to manage transactions in Spring, programmatic transactions and declarative transactions. First of all, the implementation of the two transactions is introduced in detail.

Configuration class

Configuration @ EnableTransactionManagement @ ComponentScan ("com.javashitang") public class AppConfig {@ Bean public DruidDataSource dataSource () {DruidDataSource ds = new DruidDataSource (); ds.setDriverClassName ("com.mysql.jdbc.Driver"); ds.setUrl ("jdbc:mysql://localhost:3306/test?characterEncoding=utf8&useSSL=true"); ds.setUsername ("test"); ds.setPassword ("test"); ds.setInitialSize (5) Return ds;} @ Bean public DataSourceTransactionManager dataSourceTransactionManager () {return new DataSourceTransactionManager (dataSource ());} @ Bean public JdbcTemplate jdbcTemplate (DataSource dataSource) {return new JdbcTemplate (dataSource);} @ Bean public TransactionTemplate transactionTemplate () {return new TransactionTemplate (dataSourceTransactionManager ());}} public interface UserService {void addUser (String name, String location) Default void doAdd (String name) {};} @ Service public class UserServiceV1Impl implements UserService {@ Autowired private JdbcTemplate jdbcTemplate; @ Autowired private TransactionTemplate transactionTemplate @ Override public void addUser (String name, String location) {transactionTemplate.execute (new TransactionCallbackWithoutResult () {@ Override protected void doInTransactionWithoutResult (TransactionStatus status) {try {String sql = "insert into user (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {name}) Throw new RuntimeException ("failed to save user information");} catch (Exception e) {e.printStackTrace (); status.setRollbackOnly ();});}}

You can see that the way of programming transactions is not elegant, because the business code and transaction code are coupled together, and you have to roll back the transaction manually when an exception occurs (it is more convenient than using JDBC, JDBC has to turn off autocommit first, and then manually commit or roll back the transaction as appropriate)

If you are asked to optimize the execution of the transaction method? What would you do?

"in fact, we can use AOP to optimize this code, set the pointcut, commit the transaction when the method executes successfully, and roll back the transaction when the method is abnormal. This is the principle of implementing declarative transactions."

After using AOP, when we call the transaction method, the generated proxy object is called, and the transaction commit and rollback logic is added to the proxy object.

Declarative transaction

The ways of Spring aop dynamic proxy are as follows

JDK dynamic proxy implementation (interface-based) (JdkDynamicAopProxy)

CGLIB dynamic proxy implementation (way of dynamically generating subclasses) (CglibAopProxy)

AspectJ adaptation implementation

By default, spring aop only uses JDK and CGLIB to generate proxy objects.

Where can I use @ Transactional?

@ Transactional can be used on classes, methods, and interfaces

Used on a class, all public methods of that class have transactions

Used in methods, methods have transactions. When a class and a method configure a transaction at the same time, the properties of the method override the properties of the class

This is generally not recommended when used on interfaces, because only interface-based agents take effect, and if Spring AOP uses cglib to implement dynamic proxies, it will cause transactions to fail (because annotations cannot be inherited)

@ Transactional failure scenario

The @ Transactional annotation is applied to non-public methods (unless otherwise configured, such as using AspectJ static weaving to implement AOP)

Self-calling, because @ Transactional is based on dynamic proxy implementation

The exception is try catch by yourself in the code

Incorrect exception type. Only RuntimeException and Error are supported by default, but exception checking is not supported.

Transaction propagation configuration does not conform to business logic

@ Transactional annotations are applied to non-public methods

"Why does only the @ Transactional annotation on the public method take effect?"

Prime Minister JDK dynamic proxy must only be public, because the permission modifier of the interface can only be public. The cglib proxy method can proxy the protected method (private is not allowed, the subclass cannot access the parent class's private method). If protected is supported, the performance may be different when switching the implementation of the proxy, increasing the possibility of bug waking up, so unify.

"if you want non-public methods to work, you can consider using AspectJ."

Self-calling, because @ Transactional is based on dynamic proxy implementation

When self-invoked, method execution does not pass through the proxy object, so it causes the transaction to fail. For example, when the addUser method is called as follows, the transaction is invalidated.

/ / transaction failure @ Service public class UserServiceV2Impl implements UserService {@ Autowired private JdbcTemplate jdbcTemplate; @ Override public void addUser (String name, String location) {doAdd (name);} @ Transactional public void doAdd (String name) {String sql = "insert into user (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {name}); throw new RuntimeException ("Save user failed") }}

It can be solved in the following ways

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

@ Autowired injects itself, if self, and then invokes the method through self

@ Autowired ApplicationContext, get yourself from ApplicationContext via getBean, and then call

/ / transaction takes effect @ Service public class UserServiceV2Impl implements UserService {@ Autowired private JdbcTemplate jdbcTemplate; @ Autowired private UserService userService; @ Override public void addUser (String name, String location) {userService.doAdd (name);} @ Override @ Transactional public void doAdd (String name) {String sql = "insert into user (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {name}) Throw new RuntimeException ("failed to save user");}}

The exception is try catch by yourself in the code

This logic is understood clearly from the source code. Only when the executing transaction throws an exception can you enter the completeTransactionAfterThrowing method. There is a rollback logic in this method. If the transaction method does not throw an exception, it will only commit normally.

/ / org.springframework.transaction.interceptor.TransactionAspectSupport#invokeWithinTransaction try {/ / This is an around advice: Invoke the next interceptor in the chain. / / This will normally result in a target object being invoked. / / execute transaction method retVal = invocation.proceedWithInvocation ();} catch (Throwable ex) {/ / target invocation exception completeTransactionAfterThrowing (txInfo, ex); throw ex;} finally {cleanupTransactionInfo (txInfo);}

Incorrect exception type. Only RuntimeException and Error are supported by default, but exception checking is not supported.

The diagram of the exception system is as follows. When a check exception is thrown, the spring transaction does not roll back. If any exception is thrown and rollback, you can configure rollbackFor to Exception

@ Transactional (rollbackFor = Exception.class)

Transaction propagation configuration does not conform to business logic

If there is such a scenario, the user registers, saves the basic user information to the user table in turn, and the user address information to the address table. When saving the user address information fails, we also need to ensure that the user information registration is successful.

Public interface LocationService {void addLocation (String location);} @ Service public class LocationServiceImpl implements LocationService {@ Autowired private JdbcTemplate jdbcTemplate; @ Override @ Transactional public void addLocation (String location) {String sql = "insert into location (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {location}); throw new RuntimeException ("Save address exception") } @ Service public class UserServiceV3Impl implements UserService {@ Autowired private JdbcTemplate jdbcTemplate; @ Autowired private LocationService locationService; @ Override @ Transactional public void addUser (String name, String location) {String sql = "insert into user (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {name}); locationService.addLocation (location);}}

The call found that both the user table and the location table did not insert data, which did not meet our expectations. You might say that an exception was thrown and the transaction was rolled back of course. OK, let's add try catch to the part that calls locationService

@ Service public class UserServiceV3Impl implements UserService {@ Autowired private JdbcTemplate jdbcTemplate; @ Autowired private LocationService locationService; @ Override @ Transactional public void addUser (String name, String location) {String sql = "insert into user (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {name}); try {locationService.addLocation (location) } catch (Exception e) {e.printStackTrace ();}

The call found that neither the user table nor the location table had inserted data. This is because the transaction has been marked as rollback in LocationServiceImpl, so eventually the transaction will be rolled back.

If we want to solve the problem finally, we have to mention the transaction communication behavior of Spring. The unclear partners look at "interviewer: how many kinds of communication behavior of Spring transaction?"

The transaction propagation behavior of Transactional defaults to Propagation.REQUIRED. "if a transaction currently exists, join the transaction. If there is no current transaction, create a new transaction. "

At this point, we can change the transaction propagation behavior of Transactional in LocationServiceImpl to Propagation.REQUIRES_NEW.

"create a new transaction and suspend the current transaction if it exists"

So the final solution code is as follows

@ Service public class UserServiceV3Impl implements UserService {@ Autowired private JdbcTemplate jdbcTemplate; @ Autowired private LocationService locationService; @ Override @ Transactional public void addUser (String name, String location) {String sql = "insert into user (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {name}); try {locationService.addLocation (location) } catch (Exception e) {e.printStackTrace ();} @ Service public class LocationServiceImpl implements LocationService {@ Autowired private JdbcTemplate jdbcTemplate; @ Override @ Transactional (propagation = Propagation.REQUIRES_NEW) public void addLocation (String location) {String sql = "insert into location (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {location}) Throw new RuntimeException ("Save address exception");} @ Service public class LocationServiceImpl implements LocationService {@ Autowired private JdbcTemplate jdbcTemplate; @ Override @ Transactional (propagation = Propagation.REQUIRES_NEW) public void addLocation (String location) {String sql = "insert into location (`name`) values (?)"; jdbcTemplate.update (sql, new Object [] {location}); throw new RuntimeException ("Save address exception") }} at this point, I believe you have a deeper understanding of "when Spring declarative transactions will fail". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.