アノテーションインターフェース EnableTransactionManagement


Spring の <tx:*> XML 名前空間にあるサポートと同様に、Spring のアノテーション駆動型トランザクション管理機能を有効にします。@Configuration クラスで使用して、従来の命令型トランザクション管理またはリアクティブトランザクション管理を構成します。

次の例は、PlatformTransactionManager を使用した命令型トランザクション管理を示しています。リアクティブトランザクション管理の場合は、代わりに ReactiveTransactionManager を構成します。

 @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());
     }
 }

参考のために、上記の例を次の Spring XML 構成と比較できます。

 <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>
 
上記の両方のシナリオで、@EnableTransactionManagement と  <tx:annotation-driven/> は、TransactionInterceptor や、JdbcFooRepository の @Transactional メソッドが呼び出されたときにインターセプターをコールスタックに織り込むプロキシベースまたは AspectJ ベースのアドバイスなど、アノテーション駆動型トランザクション管理を強化する必要な Spring コンポーネントの登録を担当します。

2 つの例のわずかな違いは、 TransactionManager Bean の名前付けにあります。@Bean の場合、名前は "txManager" (メソッド名による) で、XML の場合、名前は "transactionManager" です。<tx:annotation-driven/> は、デフォルトで "transactionManager" という名前の Bean を検索するようにハードワイヤードされていますが、@EnableTransactionManagement はより柔軟で、コンテナー内の任意の TransactionManager Bean に対して型別の検索にフォールバックします。名前は "txManager"、"transactionManager"、"tm" にすることができます。これはまったく問題ではありません。

@EnableTransactionManagement と使用する正確なトランザクションマネージャー Bean とのより直接的な関連を確立したい場合は、TransactionManagementConfigurer コールバックインターフェースを実装できます。以下の implements 句と @Override アノテーション付きメソッドに注意してください。

 @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();
     }
 }

このアプローチは、より明示的であるという理由だけで望ましい場合があります。または、同じコンテナーに存在する 2 つの TransactionManager Bean を区別するために必要な場合があります。名前が示すように、annotationDrivenTransactionManager() は @Transactional メソッドの処理に使用されるものになります。詳細については、TransactionManagementConfigurer Javadoc を参照してください。

mode() 属性は、アドバイスの適用方法を制御します。モードが AdviceMode.PROXY(デフォルト)の場合、他の属性がプロキシの動作を制御します。プロキシモードでは、プロキシを介した呼び出しのみのインターセプトが許可されることに注意してください。同じクラス内のローカル呼び出しは、そのようにインターセプトすることはできません。

mode()AdviceMode.ASPECTJ に設定されている場合、proxyTargetClass() 属性の値は無視されることに注意してください。また、この場合、影響を受けるクラスにアスペクトを適用するコンパイル時ウィービングまたはロード時ウィービングを使用して、spring-aspects モジュール JAR がクラスパスに存在する必要があることに注意してください。このようなシナリオに関係するプロキシはありません。ローカルコールもインターセプトされます。

導入:
3.1
作成者:
Chris Beams, Juergen Hoeller
関連事項:
  • オプション要素のサマリー

    オプション要素
    修飾子と型
    オプションの要素
    説明
    トランザクションアドバイスの適用方法を示します。
    int
    特定のジョインポイントで複数のアドバイスが適用される場合、トランザクションアドバイザーの実行の順序を示します。
    boolean
    標準の Java インターフェースベースのプロキシ(false)ではなく、サブクラスベース(CGLIB)のプロキシを作成する(true)かどうかを示します。
    カスタムロールバックルールのないルールベースのトランザクションのロールバック動作を示します。デフォルトは、チェックされていない例外でのロールバックですが、任意の例外 (チェックされたものを含む) でのロールバックに切り替えることができます。
  • 要素の詳細

    • proxyTargetClass

      boolean proxyTargetClass
      標準の Java インターフェースベースのプロキシ(false)ではなく、サブクラスベース(CGLIB)のプロキシを作成する(true)かどうかを示します。デフォルトは false です。mode() の場合のみ適用AdviceMode.PROXY に設定されます。

      この属性を true に設定すると、@Transactional でマークされているものだけでなく、プロキシを必要とするすべての Spring 管理 Bean に影響することに注意してください。例: Spring の @Async アノテーションでマークされている他の Bean は、同時にサブクラスプロキシにアップグレードされます。このアプローチは、たとえばテストで、ある型のプロキシと別の型のプロキシを明示的に期待していない限り、実際には悪影響はありません。

      デフォルト:
      false
    • mode

      トランザクションアドバイスの適用方法を示します。

      デフォルトは AdviceMode.PROXY です。プロキシモードでは、プロキシを介したコールの代行受信のみが許可されることに注意してください。同じクラス内のローカルコールはそのようにインターセプトできません。ローカル呼び出し内のそのようなメソッドの Transactional アノテーションは、Spring のインターセプターがそのようなランタイムシナリオを実行しないため、無視されます。より高度な遮断モードについては、これを AdviceMode.ASPECTJ に切り替えることを検討してください。

      デフォルト:
      PROXY
    • order

      int order
      特定のジョインポイントで複数のアドバイスが適用される場合、トランザクションアドバイザーの実行の順序を示します。

      デフォルトは Ordered.LOWEST_PRECEDENCE です。

      デフォルト:
      2147483647
    • rollbackOn

      RollbackOn rollbackOn
      カスタムロールバックルールのないルールベースのトランザクションのロールバック動作を示します。デフォルトは、チェックされていない例外でのロールバックですが、任意の例外 (チェックされたものを含む) でのロールバックに切り替えることができます。

      トランザクション固有のロールバックルールはデフォルトの動作をオーバーライドしますが、指定されていない例外に対しては選択されたデフォルトが保持されることに注意してください。これは、ここで Spring と併用される Spring の Transactional と JTA の TransactionalEE の場合に当てはまります。

      コミット動作を伴う EJB スタイルのビジネス例外に依存していない限り、(偶発的な可能性のある) チェック例外が発生した場合でも一貫したロールバックを実現するために、RollbackOn.ALL_EXCEPTIONS に切り替えることをお勧めします。また、チェック例外がまったく適用されない Kotlin ベースのアプリケーションでも、この切り替えを行うことをお勧めします。

      導入:
      6.2
      関連事項:
      デフォルト:
      RUNTIME_EXCEPTIONS