Trying to understand the declarative transaction management of Spring.
The following is from the document of Spring Release 3.2.1.
<!-- from the file 'context.xml' -->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd">
<!-- this is the service object that we want to make transactional -->
<bean id="fooService" class="x.y.service.DefaultFooService" />
<!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean
below) -->
<tx:advice id="txAdvice" transaction-manager="txManager">
<!-- the transactional semantics... -->
<tx:attributes>
<!-- all methods starting with 'get' are read-only -->
<tx:method name="get*" read-only="true" />
<!-- other methods use the default transaction settings (see below) -->
<tx:method name="*" />
</tx:attributes>
</tx:advice>
<!-- ensure that the above transactional advice runs for any execution of
an operation defined by the FooService interface -->
<aop:config>
<aop:pointcut id="fooServiceOperation"
expression="execution(* x.y.service.FooService.*(..))" />
<aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceOperation" />
</aop:config>
<!-- don't forget the DataSource -->
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy- method="close">
<property name="driverClassName" value="oracle.jdbc.driver.OracleDriver" />
<property name="url" value="jdbc:oracle:thin:@rj-t42:1521:elvis" />
<property name="username" value="scott" />
<property name="password" value="tiger" />
</bean>
<!-- similarly, don't forget the PlatformTransactionManager -->
<bean id="txManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
<!-- other <bean/> definitions here -->
</beans>
The central part is the
advisor in the <aop:config> section. It takes two arguments "advice-ref" and "pointcut-ref". Roughly speaking, an advisor advices "someone" to do "something". Here pointcut-ref is that "someone". And advice-ref is that "something". Basically what it says is to apply the advices given in "advice-ref" to those classes and/or methods defined in "pointcut-ref". So actually it is a generic thing of AOP. It is not just for transaction management.
A common requirement is to make an entire service layer transactional.The best way to do this is simply
to change the pointcut expression to match any operation in your service layer. For example:
<aop:config>
<aop:pointcut id="fooServiceMethods" expression="execution(* x.y.service.*.*(..))" />
<aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceMethods" />
</aop:config>
In this example it is assumed that all your service interfaces are defined in the x.y.service package.
Spring's declarative transaction support is enabled via AOP proxies. The AOP proxy uses a TransactionInterceptor. In the Spring Framework, an AOP proxy will be a JDK dynamic proxy or a CGLIB proxy. So underneath, the implementation uses interceptor. You can actually configure org.springframework.transaction.interceptor.TransactionInterceptor directly in XML for transaction management without using AOP.
AOP expression
Below is from Spring document (see the Reference).
Spring AOP users are likely to use the execution pointcut designator the most often. The format of
an execution expression is:
execution(modifiers-pattern? ret-type-pattern declaring-type-pattern? name-pattern(param-pattern)
throws-pattern?)
All parts except the returning type pattern (ret-type-pattern in the snippet above), name pattern, and
parameters pattern are optional. The returning type pattern determines what the return type of the
method must be in order for a join point to be matched. Most frequently you will use * as the returning
type pattern, which matches any return type. A fully-qualified type name will match only when the method
returns the given type. The name pattern matches the method name. You can use the * wildcard as all
or part of a name pattern. The parameters pattern is slightly more complex: () matches a method that
takes no parameters, whereas (..) matches any number of parameters (zero or more). The pattern (*)
matches a method taking one parameter of any type, (*,String) matches a method taking two
parameters, the first can be of any type, the second must be a String. Consult the Language Semantics
section of the AspectJ Programming Guide for more information.
Some examples of common pointcut expressions are given below.
- the execution of any public method:
execution(public * *(..))
- the execution of any method with a name beginning with "set":
execution(* set*(..))
- the execution of any method defined by the AccountService interface:
execution(* com.xyz.service.AccountService.*(..))
- the execution of any method defined in the service package:
execution(* com.xyz.service.*.*(..))
- the execution of any method defined in the service package or a sub-package:
execution(* com.xyz.service..*.*(..))
Rollback Configuration
Spring by default marks a transaction for rollback when a runtime exception is thrown. However you can customize the behavior to let the rollback happen for checked exceptions. The following is an example.
<tx:advice id="txAdvice" transaction-manager="txManager">
<tx:attributes>
<tx:method name="get*" read-only="true" rollback-for="CheckedException1, CheckedException2" />
<tx:method name="*" />
</tx:attributes>
</tx:advice>
Note that you use comma-delimited expression in the value for rollback-for. There is another attribute no-rollback-for to mark exceptions that should not trigger rollback.
Using transaction annotation
You can annotate the class with @Transactional. The following is from Spring doc.
// the service class that we want to make transactional
@Transactional
public class DefaultFooService implements FooService {
Foo getFoo(String fooName);
Foo getFoo(String fooName, String barName);
void insertFoo(Foo foo);
void updateFoo(Foo foo);
}
<!-- from the file 'context.xml' -->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd">
<!-- this is the service object that we want to make transactional -->
<bean id="fooService" class="x.y.service.DefaultFooService" />
<!-- enable the configuration of transactional behavior based on annotations -->
<tx:annotation-driven transaction-manager="txManager" />
<!-- a PlatformTransactionManager is still required -->
<bean id="txManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<!-- (this dependency is defined somewhere else) -->
<property name="dataSource" ref="dataSource" />
</bean>
<!-- other <bean/> definitions here -->
</beans>
Comparing this annotation method against the AOP XML method, you may ask what are the things corresponding to "someone" and "something" of the advisor? The annotation seems to solve the problems altogether in a completely different way. The annotation location indicates the "someone" part. And the annotation name itself indicates that transaction management needs to be carried out, which is "something".
References
- http://docs.spring.io/spring/docs/3.2.1.RELEASE/spring-framework-reference/pdf/spring-framework-reference.pdf
