Introduction to Spring's declarative transactions

Declarative Transaction Management:

Spring also provides declarative transaction management. This is achieved through spring AOP.

The usual way for transaction management in spring is to encapsulate transaction control for ordinary Java classes using AOP (for slicing programming), which is implemented through dynamic proxies, which, because the interface is lazily instantiated, loads the transaction slices through the interceptor during that time. Here's how it works, please refer to the documentation for the dynamic agent in the JDK for specific details. This article mainly explains how to control transactions in spring.
An important feature of dynamic proxies is that it is for interfaces, so we have to use the dynamic proxy to let spring take over the transaction, we have to abstract an interface in front of DAO, of course, if there is no such interface, then spring uses cglib to solve the problem, But this is not the way spring recommends, so don't discuss it.

Most spring users choose declarative transaction Management. This is the least of the choices that affect the application code, so this is consistent with the idea of a non-intrusive lightweight container.

It is useful to consider the similarities and differences between EJB CMT and Spring Declarative Transaction management. Their basic approach is similar: you can specify the transaction management to a separate method, or you can call the Setrollbackonly () method in the transaction context if necessary. The differences are as follows:

Unlike EJB CMT bindings on JTA, Spring declarative transaction management can be used in any environment. Simply change the configuration file and it can work with JDBC, JDO, hibernate, or other transaction mechanisms

Spring enables declarative transaction management to be applied to ordinary Java objects, not just special classes, such as EJB

Spring provides declarative rollback rules: EJB does not have a corresponding attribute, we will discuss this feature below. Rollback can be declarative control, not just programming-style

Spring allows you to customize transactional behavior through AOP. For example, if you want, you can insert custom behavior in a transaction rollback. You can also add arbitrary notifications, just like a transaction notification. Using EJB CMT, in addition to using setrollbackonly (), you have no way to affect the container's transaction management

Spring does not provide transactional context propagation across remote calls provided by high-end application servers. If you need these features, we recommend that you use EJBS. However, do not use these features easily. Typically, we don't want transactions to span remote calls

The concept of rollback rules is important: they allow us to specify which exceptions should initiate automatic rollback. We specify it declaratively in the configuration file, not in the Java code. So, while we can still programmatically call the Transactionstatus object's Setrollbackonly () method to roll back the current transaction, most of the time we can specify rules such as myapplicationexception should cause rollback. This has significant advantages, and the business object does not need to rely on the transactional infrastructure. For example, they usually do not need to introduce any spring APIs, transactions, or anything else.

The default behavior of the EJB is to encounter a system exception (usually a run-time exception), and the EJB container automatically rolls back the transaction. EJB CMT does not automatically roll back a transaction when it encounters an application exception (except for a checked exception outside of java.rmi.RemoteException). Although spring declarative transaction management inherits the EJB's conventions (encountering unchecked exceptions to automatically rollback transactions), this is customizable.

According to our tests, the performance of spring declarative transaction management is better than that of EJB CMT.

The spring transaction agent is typically set up through Transactionproxyfactorybean. We need a target object wrapped in the transaction agent. This target object is typically a bean for a common Java object. When we define Transactionproxyfactorybean, we must provide a reference and transaction property of the relevant platformtransactionmanager. The transaction attribute contains the transaction definition described above.

<bean id= "Petstore" class= " Org.springframework.transaction.interceptor.TransactionProxyFactoryBean "> <property name=" TransactionManager "><ref bean=" TransactionManager "/></property> <property name=" target "><
            Ref bean= "Petstoretarget"/></property> <property name= "Transactionattributes" > <props> <prop key= "insert*" >PROPAGATION_REQUIRED,-MyCheckedException</prop> <prop key= "update
        * ">PROPAGATION_REQUIRED</prop> <prop key=" * ">PROPAGATION_REQUIRED,readOnly</prop> </props> </property> </bean> 

The transaction agent implements the interface of the target object: Here is the bean with ID petstoretarget. (You can also implement a proxy for a specific class using Cglib.) Set the Proxytargetclass property to true as long as you can. If the target object does not implement any interfaces, this will automatically set the property to True. In general, we want to program for interfaces rather than classes. It is also possible to use the Proxyinterfaces property to qualify the transaction proxy to proxy the specified interface (generally a good idea). You can also customize the behavior of Transactionproxyfactorybean by inheriting from Org.springframework.aop.framework.ProxyConfig or by attributes shared by all AOP agent factories.

The Transactionattributes attribute here is defined in the Org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource To set the property format in the. This method name mapping, which includes wildcard characters, is straightforward. Note the values of the mappings for insert* include rollback rules. The added-mycheckedexception specifies that if the method throws mycheckedexception or its subclasses, the transaction is automatically rolled back. You can define multiple rollback rules by separating them with commas. -Prefix force rollback, + prefix specify commit (this allows the transaction to be committed even if the unchecked exception is thrown, of course you have to understand what you are doing).

Transactionproxyfactorybean allows you to set the "Preinterceptors" and "postinterceptors" properties to provide additional interception behavior by setting "before" or "after" notifications. You can set any number of "before" and "after" notifications, which can be of the type Advisor (which can contain a pointcut), methodinterceptor or the type of notification supported by the current spring configuration (for example, Throwadvice, Afterreturningtadvice or Beforeadvice, which are supported by default). These notifications must support instance sharing mode. If you need advanced AOP features to use transactions, such as stateful maxin, it's best to use a generic Org.springframework.aop.framework.ProxyFactoryBean, Instead of the Transactionproxyfactorybean utility proxy creator.

You can also set up automatic proxies: Configure the AOP framework, and you can generate proxies for classes without requiring a separate proxy definition class.

All transaction policies in a spring are attached

Propagation_mandatory
propagation_nested
Propagation_never
propagation_not_supported
Propagation_required
Propagation_required_new
Propagation_supports

All quarantine policies in spring B are attached:

Isolation_default
isolation_read_uncommited
isolation_commited
Isolation_repeatable_read
Isolation_serializable