Declarative transaction management:
Spring also provides declarative transaction management. This is implemented through Spring AOP.
In spring, transaction management is usually implemented by using AOP (slice-Oriented Programming) to encapsulate transaction control for common Java classes. It is implemented through dynamic proxy, because the interface is delayed in instantiation, spring loads transaction slices through the interceptor during this period. This is the principle. For details, see the documentation on dynamic proxy in JDK. This article describes how to control transactions in spring.
An important feature of dynamic proxy is that it targets interfaces. Therefore, to allow spring to take over transactions through dynamic proxy, We must abstract an interface before Dao, of course, if such an interface is not available, spring will use cglib to solve the problem, but this is not the method recommended by spring, so we will not discuss it.
Most spring users choose declarative transaction management. This is the choice that has minimal impact on application code, so this is the sameNon-invasiveThe concept of lightweight containers is consistent.
It is helpful to consider the similarities and differences between ejb cmt and spring declarative transaction management. Their basic methods are similar: You can specify individual methods for transaction management. If necessary, you can callSetrollbackonly ()Method. The differences are as follows:
Unlike ejb cmt binding to JTA, spring declarative transaction management can be used in any environment. You only need to change the configuration file to work with JDBC, JDO, hibernate, or other transaction mechanisms.
Spring enables declarative transaction management to be applied to common Java objects, not just special classes, such as EJB.
Spring provides declarativeRollback rules: EJB does not have a corresponding feature. We will discuss this feature below. Rollback can be declarative, not just programmatic
Spring allows you to customize transaction behavior through AOP. For example, if necessary, you can insert custom behaviors in transaction rollback. You can also add any notifications, just like transaction notifications. Use ejb cmt, exceptSetrollbackonly (), You cannot influence the container's Transaction Management
Spring does not provide transaction context propagation across remote calls provided by high-end application servers. If you need these features, we recommend that you use EJB. However, do not use these features easily. Generally, we do not want transactions to be called remotely.
The concept of rollback rules is very important: they allow us to specify which exceptions should initiate auto-dynamic rollback. In the configuration file rather than in Java code, we specify it in Declaration. Therefore, although we can still program callTransactionstatusObjectSetrollbackonly ()Method to roll back the current transaction. In most cases, we can specify rules, as shown in figureMyapplicationexceptionIt should cause rollback. This has a significant advantage that business objects do not need to rely on the transaction infrastructure. For example, they usually do not need to be introduced into any spring API, transaction or anything else.
The default behavior of EJB isSystem exception(Usually an exception during running), The EJB container automatically rolls back the transaction. Ejb cmt encounteredApplication exception(Java. RMI. RemoteExceptionIs not automatically rolled back. Although spring declarative Transaction Management follows the EJB conventions (automatic rollback of transactions when an unchecked exception occurs), this can be customized.
According to our tests, the performance of spring declarative transaction management is better than that of EJB cmt.
Generally, the Spring transaction proxy is set through transactionproxyfactorybean. We need a target object packaged in the transaction proxy. This target object is generally a bean of a common Java object. When we define transactionproxyfactorybean, we must provide a reference andTransaction attributes.Transaction attributesContains 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 proxy will implement the interface of the target object: Here is the bean with ID petstoretarget. (Cglib can also be used as a proxy for specific classes. You only need to set the property of proxytargetclass to true. If the target object does not implement any interfaces, this attribute is automatically set to true. In general, we want to be interface-oriented rather than class programming .) It is also possible to use the proxyinterfaces attribute to limit the transaction proxy to manage specified interfaces (generally, this is a good idea ). You can alsoOrg. springframework. AOP. Framework. proxyconfigInherit or all attributes shared by the AOP proxy factory to customize the behavior of transactionproxyfactorybean.
The transactionattributes attribute is defined inOrg. springframework. transaction. Interceptor. namematchtransactionattributesourceTo set the attribute format. This method name ing includes wildcards is intuitive. Note that the ing values of insert * include rollback rules. Added-MycheckedexceptionSpecify if the method throwsMycheckedexceptionOr its subclass, the transaction will be automatically rolled back. Multiple rollback rules can be defined by commas.-Forcibly roll back with a prefix and specify a submission with a prefix(This allows you to commit transactions even if an unchecked exception is thrown. Of course, you must understand what you are doing ).
TransactionproxyfactorybeanYou can use the "preinterceptors" and "postinterceptors" attributes to set "before" or "after" notifications to provide additional interception behaviors. You can set any number of "before" and "after" notifications. Their types can beAdvisor(You can include an entry point ),MethodinterceptorOr the notification type supported by the current spring configuration (for exampleThrowadvice,AfterreturningtadviceOrBeforeadvice). These notifications must support the instance sharing mode. If you need advanced AOP features to use transactions, it is best to use commonOrg. springframework. AOP. Framework. proxyfactorybeanInsteadTransactionproxyfactorybeanThe creator of the utility proxy.
You can also set Automatic Proxy: configure the AOP framework and generate a class proxy without a separate proxy definition class.
Appendix A all transaction policies in spring
Propagation_mandatory
Propagation_nested
Propagation_never
Propagation_not_supported
Propagation_required
Propagation_required_new
Propagation_supports
Appendix B all isolation policies in Spring:
Isolation_default
Isolation_read_uncommited
Isolation_commited
Isolation_repeatable_read
Isolation_serializable