Spring declarative transaction management, implementing declarative transaction management through spring AOP:
Quote: http://www.javaeye.com/post/343748
Spring also provides declarative transaction management. This is implemented through spring AOP.
The usual way of doing transaction management in spring is to encapsulate transaction control for ordinary Java classes using AOP (slicing-oriented programming), which is implemented through dynamic proxies, which spring uses as an interceptor to load transaction slices during this time, because the interface is deferred instantiation. Here's how it works, please refer to the JDK's documentation for dynamic proxies in the details. This article focuses on how to handle transaction control in spring.
An important feature of dynamic proxies is that it is for interfaces, so our DAO has to abstract an interface in front of the DAO in order to let spring take over the transaction through a dynamic proxy, of course, if there is no such interface, then spring will use Cglib to solve the problem. But that's not the way spring is recommended, so don't talk about 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 concept 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 transaction management to a separate method, and you can call the Setrollbackonly () method in the transaction context if you need to. The differences are as follows:
Unlike EJB CMT bindings on JTA, Spring declarative transaction management can be used in any environment. By simply changing the configuration file, 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 a declarative rollback rule: ejbs do not have corresponding attributes, and we will discuss this feature below. Rollback can be declarative control, not just a programmatic
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 any notice, just like a transaction notice. With EJB CMT, you have no way to affect the transaction management of a container other than using setrollbackonly ()
Spring does not provide transaction context propagation across remote invocations provided by high-end application servers. If you need these features, we recommend that you use EJBS. However, do not use these features lightly. Usually we don't want the transaction to cross the remote call
The concept of rollback rules is important: they allow us to specify which exceptions should initiate an automatic rollback. We specify it in the configuration file, not in Java code, in a declarative way. Therefore, while we can still programmatically invoke the Transactionstatus object's Setrollbackonly () method to roll back the current transaction, most of the time we can specify the rule, such as myapplicationexception should result in a rollback. This has the obvious advantage that business objects do not need to rely on the transaction 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 system exceptions (usually run-time exceptions), and the EJB container automatically rolls back the transaction. The EJB CMT does not automatically rollback the transaction when it encounters an application exception (except for a checked exception outside java.rmi.RemoteException). Although spring declarative transaction management follows the convention of EJB (encounters unchecked exception auto ROLLBACK TRANSACTION), this can be customized.
According to our tests, the performance of spring declarative transaction management is better than 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 of a normal Java object. When we define Transactionproxyfactorybean, we must provide an associated Platformtransactionmanager reference and transaction attributes. The transaction attribute contains the transaction definition described above.
Java code
<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>
<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: This is the bean with ID petstoretarget. (You can also implement proxies for specific classes using Cglib.) You can only set the Proxytargetclass property to True. This property is automatically set to True if the target object does not implement any interfaces. In general, we want to interface with interfaces rather than class programming. It is also OK to use the Proxyinterfaces property to qualify the transaction agent to proxy the specified interface (generally a good idea). You can also customize Transactionproxyfactorybean behavior by inheriting from Org.springframework.aop.framework.ProxyConfig or by using properties that are 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 insert* mappings include rollback rules. Added-mycheckedexception specifies that if the method throws a mycheckedexception or its subclass, the transaction is automatically rolled back. You can define multiple rollback rules by separating them with commas. -Prefix force rollback, + prefix to specify commit (this allows the transaction to be committed even if a unchecked exception is thrown, and of course you have to know what you are doing).
Transactionproxyfactorybean allows you to set "pre" or "post" notifications via the "Preinterceptors" and "postinterceptors" properties to provide additional blocking behavior. You can set any number of "before" and "post" notifications, and their types can be Advisor (which can contain a pointcut), methodinterceptor, or the type of notification that is supported by the current spring configuration (for example, Throwadvice, Afterreturningtadvice or Beforeadvice, these 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 is best to use generic Org.springframework.aop.framework.ProxyFactoryBean, Instead of the Transactionproxyfactorybean utility Agent creator.
You can also set up automatic proxies: Configure the AOP framework to generate a proxy for the class without requiring a separate proxy definition class.
Attach all transaction strategies in a spring
Propagation_mandatory
propagation_nested
Propagation_never
propagation_not_supported
Propagation_required
Propagation_required_new
Propagation_supports
Attached to all quarantine strategies in spring B:
Isolation_default
isolation_read_uncommited
isolation_commited
Isolation_repeatable_read
Isolation_serializable
