Package org.springframework.transaction.annotation

# Annotation Interface EnableTransactionManagement

@Target(TYPE) @Retention(RUNTIME) @Documented @Import(TransactionManagementConfigurationSelector.class) public @interface EnableTransactionManagement
Enables Spring's annotation-driven transaction management capability, similar to the support found in Spring's `<tx:*>` XML namespace. To be used on `@Configuration` classes to configure traditional, imperative transaction management or reactive transaction management.

The following example demonstrates imperative transaction management using a `PlatformTransactionManager`. For reactive transaction management, configure a `ReactiveTransactionManager` instead.

     @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 weaves 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 `TransactionManager` bean: In the `@Bean` case, the name is "txManager" (per the name of the method); in the XML case, the name is "transactionManager". `<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 `TransactionManager` 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 `TransactionManager` 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.

Since:
  3.1
Author:
  Chris Beams, Juergen Hoeller
See Also:
  - `TransactionManagementConfigurer`
  - `TransactionManagementConfigurationSelector`
  - `ProxyTransactionManagementConfiguration`
  - `org.springframework.transaction.aspectj.AspectJTransactionManagementConfiguration`

## Optional Element Summary

Optional Elements
Modifier and Type
Optional Element
Description
`org.springframework.context.annotation.AdviceMode`
`mode`
Indicate how transactional advice should be applied.
`int`
`order`
Indicate the ordering of the execution of the transaction advisor when multiple advices are applied at a specific joinpoint.
`boolean`
`proxyTargetClass`
Indicate whether subclass-based (CGLIB) proxies are to be created (`true`) as opposed to standard Java interface-based proxies (`false`).
`RollbackOn`
`rollbackOn`
Indicate the rollback behavior for rule-based transactions without custom rollback rules: default is rollback on unchecked exception, this can be switched to rollback on any exception (including checked).

## Element Details

### proxyTargetClass

boolean proxyTargetClass
Indicate whether subclass-based (CGLIB) proxies are to be created (`true`) as opposed to standard Java interface-based proxies (`false`). The default is `false`. Applicable only if `mode()` is set to `AdviceMode.PROXY`.

Note that setting this attribute to `true` will affect all Spring-managed beans requiring proxying, not just those marked with `@Transactional`. For example, other beans marked with Spring's `@Async` annotation will be upgraded to subclass proxying at the same time. This approach has no negative impact in practice unless one is explicitly expecting one type of proxy vs another, for example, in tests.

Default:
  false

### mode

org.springframework.context.annotation.AdviceMode mode
Indicate how transactional advice should be applied.

The default is `AdviceMode.PROXY`. 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; an `Transactional` annotation on such a method within a local call will be ignored since Spring's interceptor does not even kick in for such a runtime scenario. For a more advanced mode of interception, consider switching this to `AdviceMode.ASPECTJ`.

Default:
  PROXY

### order

int order
Indicate the ordering of the execution of the transaction advisor when multiple advices are applied at a specific joinpoint.

The default is `Ordered.LOWEST_PRECEDENCE`.

Default:
  2147483647

### rollbackOn

RollbackOn rollbackOn
Indicate the rollback behavior for rule-based transactions without custom rollback rules: default is rollback on unchecked exception, this can be switched to rollback on any exception (including checked).

Note that transaction-specific rollback rules override the default behavior but retain the chosen default for unspecified exceptions. This is the case for Spring's `Transactional` as well as JTA's `Transactional` when used with Spring here.

Unless you rely on EJB-style business exceptions with commit behavior, it is advisable to switch to `RollbackOn.ALL_EXCEPTIONS` for a consistent rollback even in case of a (potentially accidental) checked exception. Also, it is advisable to make that switch for Kotlin-based applications where there is no enforcement of checked exceptions at all.

Since:
  6.2
See Also:
  - `Transactional.rollbackFor()`
  - `Transactional.noRollbackFor()`
  - `Transactional.rollbackOn()`
  - `Transactional.dontRollbackOn()`

Default:
  RUNTIME_EXCEPTIONS