spring-framework / org.springframework.transaction.annotation

Package org.springframework.transaction.annotation

Types

AnnotationTransactionAttributeSource

 open class AnnotationTransactionAttributeSource : AbstractFallbackTransactionAttributeSource, Serializable

Implementation of the org.springframework.transaction.interceptor.TransactionAttributeSource interface for working with transaction metadata in JDK 1.5+ annotation format.

This class reads Spring's JDK 1.5+ Transactional annotation and exposes corresponding transaction attributes to Spring's transaction infrastructure. Also supports JTA 1.2's javax.transaction.Transactional and EJB3's javax.ejb.TransactionAttribute annotation (if present). This class may also serve as base class for a custom TransactionAttributeSource, or get customized through TransactionAnnotationParser strategies.

Ejb3TransactionAnnotationParser

 open class Ejb3TransactionAnnotationParser : TransactionAnnotationParser, Serializable

Strategy implementation for parsing EJB3's javax.ejb.TransactionAttribute annotation.

JtaTransactionAnnotationParser

 open class JtaTransactionAnnotationParser : TransactionAnnotationParser, Serializable

Strategy implementation for parsing JTA 1.2's javax.transaction.Transactional annotation.

ProxyTransactionManagementConfiguration

 open class ProxyTransactionManagementConfiguration : AbstractTransactionManagementConfiguration

@Configuration class that registers the Spring infrastructure beans necessary to enable proxy-based annotation-driven transaction management.

SpringTransactionAnnotationParser

 open class SpringTransactionAnnotationParser : TransactionAnnotationParser, Serializable

Strategy implementation for parsing Spring's Transactional annotation.

Annotations

EnableTransactionManagement

 class EnableTransactionManagement

Enables Spring's annotation-driven transaction management capability, similar to the support found in Spring's <tx:*> XML namespace. To be used on org.springframework.context.annotation.Configuration classes as follows: 

 @Configuration @EnableTransactionManagement public class AppConfig { @Bean public FooRepository fooRepository() { // configure and return a class having @Transactional methods return new JdbcFooRepository(dataSource()); } @Bean public DataSource dataSource() { // configure and return the necessary JDBC DataSource } @Bean public PlatformTransactionManager txManager() { return new DataSourceTransactionManager(dataSource()); } }

For reference, the example above can be compared to the following Spring XML configuration: 

<beans> <tx:annotation-driven/> <bean id="fooRepository" class="com.foo.JdbcFooRepository"> <constructor-arg ref="dataSource"/> </bean> <bean id="dataSource" class="com.vendor.VendorDataSource"/> <bean id="transactionManager" class="org.sfwk...DataSourceTransactionManager"> <constructor-arg ref="dataSource"/> </bean> </beans>
In both of the scenarios above, @EnableTransactionManagement and <tx:annotation-driven/> are responsible for registering the necessary Spring components that power annotation-driven transaction management, such as the TransactionInterceptor and the proxy- or AspectJ-based advice that weave the interceptor into the call stack when JdbcFooRepository's @Transactional methods are invoked.

A minor difference between the two examples lies in the naming of the PlatformTransactionManager bean: In the @Bean case, the name is "txManager" (per the name of the method); in the XML case, the name is "transactionManager". The <tx:annotation-driven/> is hard-wired to look for a bean named "transactionManager" by default, however @EnableTransactionManagement is more flexible; it will fall back to a by-type lookup for any PlatformTransactionManager bean in the container. Thus the name can be "txManager", "transactionManager", or "tm": it simply does not matter.

For those that wish to establish a more direct relationship between @EnableTransactionManagement and the exact transaction manager bean to be used, the TransactionManagementConfigurer callback interface may be implemented - notice the implements clause and the @Override-annotated method below: 

 @Configuration @EnableTransactionManagement public class AppConfig implements TransactionManagementConfigurer { @Bean public FooRepository fooRepository() { // configure and return a class having @Transactional methods return new JdbcFooRepository(dataSource()); } @Bean public DataSource dataSource() { // configure and return the necessary JDBC DataSource } @Bean public PlatformTransactionManager txManager() { return new DataSourceTransactionManager(dataSource()); } @Override public PlatformTransactionManager annotationDrivenTransactionManager() { return txManager(); } }
This approach may be desirable simply because it is more explicit, or it may be necessary in order to distinguish between two PlatformTransactionManager beans present in the same container. As the name suggests, the annotationDrivenTransactionManager() will be the one used for processing @Transactional methods. See TransactionManagementConfigurer Javadoc for further details.

The #mode attribute controls how advice is applied: If the mode is AdviceMode#PROXY (the default), then the other attributes control the behavior of the proxying. Please note that proxy mode allows for interception of calls through the proxy only; local calls within the same class cannot get intercepted that way.

Note that if the #mode is set to AdviceMode#ASPECTJ, then the value of the #proxyTargetClass attribute will be ignored. Note also that in this case the spring-aspects module JAR must be present on the classpath, with compile-time weaving or load-time weaving applying the aspect to the affected classes. There is no proxy involved in such a scenario; local calls will be intercepted as well.