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

This article mainly explains the communication behavior description of transactions in Spring and how to manage transactions. The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how to explain the propagation behavior of transactions in Spring and how to manage transactions.

When we call a method in Service in spring, if we configure transaction management for Service by default, then Service will run in a transactional environment managed by spring. Because in our daily development, we usually call the interfaces in other Service in one Service interface to complete a complete transaction operation, then the nested invocation of the service interface occurs. Spring controls how the current transaction propagates to the nested target service interface method through transaction propagation behavior. Let's take a look at the different transaction propagation behaviors in spring and their differences in the past.

Spring defines seven types of transaction propagation behaviors in the TransactionDefinition interface. The differences between them are as follows:

Description of transaction propagation behavior

PROPAGATION_REQUIRED: if there is no current transaction, create a new transaction, and if one already exists, join it.

PROPAGATION_SUPPORTS: supports the current transaction and, if there is no transaction, executes in a non-transactional way.

PROPAGATION_MANDATORY: uses the current transaction and throws an exception if there is no current transaction.

PROPAGATION_REQUIRES_NEW: create a new transaction and suspend the current transaction if it exists.

PROPAGATION_NOT_SUPPORTED: performs the operation in a non-transactional manner, suspending the current transaction if there is a current transaction.

PROPAGATION_NEVER: executes in a non-transactional manner, and throws an exception if a transaction exists

PROPAGATION_NESTED: if there is a transaction, it is executed within a nested transaction, and if there is no transaction, an operation similar to PROPAGATION_REQUIRED is performed.

Note: when PROPAGATION_NESTED is enabled, the underlying data source must be based on JDBC3.0, and the implementer needs to support the save point transaction mechanism.

When we are in actual development, we basically do not manage transactions by coding, because it is very inconvenient to manage. In actual development, we generally use xml or annotation methods to manage transactions. Although we do not directly use a coded approach to transaction management, support for this approach is provided in spring. We can directly use the TransactionTemplate template class provided to us by spring to perform the management of the transaction in a coded manner. Let's take a brief look at the main methods of the TransactionTemplate template class.

Let's take a look at how to use the ransactionTemplate template class to manage transactions through coding through a simple test case.

Because the spring transaction manager TransactionSynchronizationManager works, if you need the access database connection shown in the callback interface method, you must get the thread-bound data connection through the resource acquisition utility class, because this is the underlying protocol of spring transaction management. If the DAO interface is created based on the template class provided by spring, because the template class has internally used the resource acquisition tool class to obtain database connections, users do not have to worry about the acquisition of underlying data connections.

As we mentioned above, instead of managing transactions in a coded way during our daily development, we basically use declarative transaction management capabilities because this allows transaction management code to be completely decoupled from business code. Declarative transaction management in spring is implemented through the functionality of spring AOP. The specific process is through the declaration information of the transaction, and spring is responsible for dynamically weaving the transaction management enhancement logic into the corresponding join point of the business method. Let's manage the transaction through the xml code.

There are two methods in the UserDao interface, and we can add the transaction ability to write to the save method and the read transaction ability to the getUserInfo method.

We can see that there is a big difference between using xml to manage transactions and using coding directly. In the implementation class of the interface, there is only the relevant business code, and there will not be any related transaction code, while the direct coding method must manually write the code for managing transactions in the interface implementation class. In spring, there are two ways to manage transactions through xml, one is to manage transactions through TransactionProxyFactoryBean, and the other is to manage transactions through tx, because TransactionProxyFactoryBean is no longer recommended in the spring official website, so our following test cases will use tx to manage transactions.

Thank you for your reading, the above is the content of "the communication behavior description of affairs in Spring and how to manage transactions". After the study of this article, I believe you have a deeper understanding of the communication behavior description of transactions in Spring and how to manage transactions, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.