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

This article will explain in detail how to manage Spring affairs for you. The editor thinks it is very practical, so I share it with you as a reference. I hope you can get something after reading this article.

Spring transaction Abstract PlatformTransactionManager is the transaction manager interface / / transaction manager interface has the following interfaces to obtain transaction information, commit and roll back public interface PlatformTransactionManager {TransactionStatus getTransaction (@ Nullable TransactionDefinition var1) throws TransactionException; void commit (TransactionStatus var1) throws TransactionException; void rollback (TransactionStatus var1) throws TransactionException;} there are several common transaction managers

DataSourceTransactionManager

HibernateTransactionManager

JtaTransactionManager

These managers all implement three interfaces in PlatformTransactionManager, and the implementation logic is slightly different, but there is little difference for users.

Define some parameters for the transaction:

The parameters of some transactions are in TransactionDefinition.java, as shown below:

Public interface TransactionDefinition {int PROPAGATION_REQUIRED = 0; int PROPAGATION_SUPPORTS = 1; int PROPAGATION_MANDATORY = 2; int PROPAGATION_REQUIRES_NEW = 3; int PROPAGATION_NOT_SUPPORTED = 4; int PROPAGATION_NEVER = 5; int PROPAGATION_NESTED = 6; / / the default isolation level is the same as the isolation level of the database int ISOLATION_DEFAULT =-1; int ISOLATION_READ_UNCOMMITTED = 1 Int ISOLATION_READ_COMMITTED = 2; int ISOLATION_REPEATABLE_READ = 4; int ISOLATION_SERIALIZABLE = 8; / / No timeout int TIMEOUT_DEFAULT =-1;}

These parameters are illustrated in the following two figures:

7 transaction propagation features:

There are four transaction isolation levels:

Before looking at the transaction isolation level, we need to understand what dirty reading, non-repeatable reading and phantom reading are.

Dirty reading: dirty reading is the uncommitted data of one thing that is read by another transaction, which is obviously unacceptable.

Non-repeatable reading: non-repeatable reading means that the same data is read many times in a transaction, and the results are inconsistent.

Illusion: transaction A modifies one of the data in the table, which involves all the rows of data in the table. Transaction B also modifies the data in the table by inserting a row of new data into the table. Then the user of transaction A will find that there are still unmodified data rows in the table, as if there were hallucinations.

With the above concepts in mind, let's look at the isolation level:

Here we can see that Spring does not provide all the implementation of transaction management, but provides a standard operation interface of transaction manager PlatformTransactionManager, and standardizes its behavior, and the specific transaction implementation is implemented by each platform. This is the transaction abstraction of Spring.

Programming transactions of Spring

Spring provides TransactionTemplate utility classes that make it easy to use programmatic transactions. By default, TransactionTemplate uses DataSourceTransactionManager.

In the context of Spring, we can get TransactionTemplate without configuring the bean of TransactionTemplate. For example, the following example.

@ Servicepublic class UserInfoService {@ Resource private UserInfoDAO userInfoDAO; @ Autowired private TransactionTemplate transactionTemplate; public void updateUser1 () {transactionTemplate.execute (transactionStatus-> {userInfoDAO.updateUserName (1, "zhangsanfeng"); transactionTemplate.execute (transactionStatus2-> {userInfoDAO.updateUserName (2, "lisi"); return null;}); return null;}) }}

Since the default transaction propagation feature of Spring is PROPAGATION_REQUIRED, let's do some verification to see if this is the case.

As you can see from the above two figures, the newTransaction attribute in TransactionStatus, the first is true and the second is false, which coincides with the situation described by PROPAGATION_REQUIRED. Other communication features can be verified by yourself.

Declarative transaction

In addition to programmatic transactions, Spring also provides us with declarative transactions. Use the @ Transactional annotation.

@ Transactional can act on interfaces, interface methods, classes, and class methods. When acting on a class, all public methods of that class will have transactional properties of that type, and we can also use this annotation at the method level to override the class-level definition.

Although the @ Transactional annotation can be applied to interfaces, interface methods, classes, and class methods, Spring recommends that it not be used on interfaces or interface methods, as it only takes effect when using interface-based proxies. In addition, the @ Transactional annotation should only be applied to public methods, which is determined by the nature of Spring AOP. If you use the @ Transactional annotation on protected, private, or default visibility methods, this will be ignored and no exception will be thrown.

The rollbackFor property of @ Transactional can set an array of Throwable to indicate that a transaction rollback occurs if the method throws these exceptions. By default, if the rollbackFor property is not configured, the transaction will only be rolled back when it encounters RuntimeException.

The following code transaction will not take effect:

@ Transactional public void updateUser2 () throws Exception {int R1 = userInfoDAO.updateUserName (1, "wanger"); int R2 = userInfoDAO.updateUserName (2, "mawu"); if (R2 room1) {throw new Exception ();}}

If we change the exception thrown to RuntimeException, the transaction will take effect. Or specify an exception for the transaction to take effect, such as @ Transactional (rollbackFor = Exception.class), so that all exception transactions will take effect.

Why do things take effect with @ Transactional annotations?

This is because the Spring container generates a proxy object for the annotated object, which is actually the calling proxy object when called. The proxy object realizes the enhancement of AOP and the realization of transaction.

How do you achieve the specified propagation characteristics and isolation level through annotations? Public @ interface Transactional {@ AliasFor ("transactionManager") String value () default ""; @ AliasFor ("value") String transactionManager () default ""; String [] label () default {}; Propagation propagation () default Propagation.REQUIRED; Isolation isolation () default Isolation.DEFAULT; int timeout () default-1; String timeoutString () default "; boolean readOnly () default false; Class"

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.