トランザクションマネージャを利用することで、トランザクションの制御を細かく設定できる。またトランザクションの制御も複雑になっているので、その辺も確認する。

トランザクションマネージャ3つの利用方法

Bean定義する
- PlatformTransactionManagerの実装クラスをBean定義する
- Adviceの設定をするどのようなメソッドの時に、どのような設定でトランザクションを行うかを記載
  - どのようなメソッドの時に、どのような設定でトランザクションを行うかを記載
アノテーションによる宣言的トランザクション
- @Transactionalアノテーションを使う。一番使いやすい。
- アノテーションの要素にトランザクションの定義情報を記載できる
- Proxyを介してトランザクションが行われる
明示的トランザクション
- ソースコード上でPlatformTransactionManagerから提供されるメソッドを利用してトランザクションの制御を行う
- 同一クラス内の処理の一部でトランザクション処理を行いたい場合(Proxyを介さない)に対応できる通常は宣言的トランザクションを利用すれば良いです
  - 通常は宣言的トランザクションを利用すれば良いです

今回は明示的トランザクションについて見ていきますが、軽くアノテーションを使う宣言的トランザクションも見ていきます。明示的トランザクションを見る理由は、APIの使い方がわかりやすいからです。※宣言的トランザクションの利用が推奨されているらしいです。

トランザクションマネージャの実装クラス

DataSourceTransactionManager
- 1つのデータソースに対してトランザクション制御を行う
HibernateTransactionManager
- Hibernate用
JpaTransactionManager
- JPAのEntityManagerに対してトランザクション制御を行う
JtaTransactionManager
- JTA用

使用するデータアクセス技術に合わせて利用する。

PlatformTransactionManager

全てのトランザクションマネージャが実装しているインターフェースです。

公開されているメソッド

getTransaction
commit
rollback

下の2つは想像通りの動きをすると思います。

getTransactionは指定された伝搬動作に従って、現在アクティブなトランザクションを返すか、新しいトランザクションを返すそうです。以下は実装の一部で、見る限りトランザクションを開始してトランザクションを返しています

else if (def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRED ||
		def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW ||
		def.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
	SuspendedResourcesHolder suspendedResources = suspend(null);
	if (debugEnabled) {
		logger.debug("Creating new transaction with name [" + def.getName() + "]: " + def);
	}
	try {
		return startTransaction(def, transaction, debugEnabled, suspendedResources);
	}
	catch (RuntimeException | Error ex) {
		resume(null, suspendedResources);
		throw ex;
	}
}

パラメータのdefinitionは、伝搬の動作、分離レベル、タイムアウトなどを記述したTransactionDefinition のインスタンス (デフォルトでは NULL も可能)。とのことなので、TransactionDefinitionこそが
伝搬動作
- この3つの伝搬動作はトランザクションを開始する動作を表しています。

伝搬動作

トランザクション制御に利用している伝搬動作は重要なのが2つあります

伝搬属性
独立性レベル

伝搬属性

上記コードにも出てきましたが、TransactionDefinition.PROPAGATION_REQUIREDなどが伝搬属性です。どれもトランザクションを開始するという意味ですが、別のトランザクションから呼ばれた時の振る舞いが異なります。

PROPAGATION_REQUIRED
- トランザクションを開始する
- ただし別のトランザクションから呼ばれた時は、そのトランザクションに参加する
PROPAGATION_REQUIRES_NEW
- トランザクションを開始する
- ただし別のトランザクションから呼ばれた時は、新しいトランザクションを開始する
PROPAGATION_NESTED
- トランザクションを開始する
- ただし別のトランザクションから呼ばれた時は、部分的なトランザクションを開始する
PROPAGATION_MANDATORY
- 例外を投げる
- ただし別のトランザクションから呼ばれた時は、そのトランザクションに参加する

例えば採番処理なんかは、多くの機能から呼ばれることになるので常に新しいトランザクションを開始(PROPAGATION_REQUIRES_NEW)を選択しても良いでしょう。

また在庫更新などは、出荷や受注などの機能と同時に呼ばれることが前提になるのでPROPAGATION_MANDATORYを選択するべきです。

他にもトランザクションを開始しない(PROPAGATION_SUPPORTS)などの伝搬属性があります。

PROPAGATION_SUPPORTSは正確には、トランザクションを行わないが、他のトランザクションから呼ばれた時は、そのトランザクションに参加します。

完全にトランザクションを開始しない場合はPROPAGATION_NOT_SUPPORTEDを利用します。

独立性レベル

簡単に言うと「別のトランザクションが更新したけどコミットしてないデータの扱い方」みたいなものだと思います。

更新したけどコミットしていないということは、のちにロールバックされる可能性がある=不確定な状態ということです。

そういった不確定な状態のデータを矛盾なく処理を行う性質が独立性です。

デフォルトがISOLATION_DEFAULT(データベースに依存する)ということになっています。

データ矛盾が生じる状態

Dirty Read
- 他のトランザクションが変更してコミットしていないデータを読み出すことDirty = 汚い
  - Dirty = 汚い
Unrepeatable Read
- トランザクションが同じデータを複数回読み出す時に、他のトランザクションが途中でそのデータを更新すると、以前と違うデータを読み出してしまうことUnrepeatable = 繰り返し不可能
  - Unrepeatable = 繰り返し不可能
Phantom Read
- トランザクションが同じデータを複数回読み出す時に、他のトランザクションが途中でレコードを追加すると、以前は存在しなかったレコードを読み出してしまうことPhantom = 幽霊
  - Phantom = 幽霊

下に行くほど独立性レベルが強く矛盾を許さない。独立性レベルが強くなるとパフォーマンスが悪くなる。処理対象のレコードやテーブルにロックをかけて他方のトランザクションの処理を持たせることで独立性を確保することが多い（データベースによって異なる）

ソースのコメントAI翻訳すると以下のようになりました

ISOLATION_READ_UNCOMMITTED
- ダーティリード、非再現性リード、ファントムリードが発生する可能性があることを示します。このレベルでは、あるトランザクションで変更された行を、その行の変更がコミットされる前に別のトランザクションで読み取ることができます（”ダーティリード”）。変更のいずれかがロールバックされると、2番目のトランザクションは無効な行を取得したことになります。
READ_COMMITTED
- ダーティな読み取りが防止されることを示します。繰り返し不可能な読み取りやファントム・リードは発生する可能性があります。このレベルは、トランザクションがコミットされていない変更のある行を読み取ることを禁止するだけです。
ISOLATION_REPEATABLE_READ
- ダーティリードと非再現性リードが禁止されていることを示しますが、ファントムリードが発生する可能性があります。このレベルでは、トランザクションがコミットされていない変更のある行を読み取ることを禁止します。また、あるトランザクションが行を読み取り、2番目のトランザクションがその行を変更し、最初のトランザクションが行を再読み取りして2回目に異なる値を取得するという状況（「非再現性読み取り」）も禁止されます。
ISOLATION_SERIALIZABLE
- ダーティリード、非再現性リード、ファントム・リードが防止されていることを示します。このレベルはISOLATION_REPEATABLE_READの禁止事項を含み、さらに、あるトランザクションがWHERE条件を満たすすべての行を読み取り、2番目のトランザクションがそのWHERE条件を満たす行を挿入し、最初のトランザクションが同じ条件で再読み取りし、2番目の読み取りで追加の「ファントム」行を取得するという状況を禁止している。

デフォルトで困ったら考えればいいのかな？これで思い出したけど、トランザクションかかってんだからデータを読み出せないじゃん！ってなったことがあったけど、独立性をいじれば良かったのか？（フレームワークで設定してていじれなかったと思うのですが・・・）完全に独り言です。すみません。。。

他のトランザクション定義情報

タイムアウト
- トランザクションがキャンセルされるタイムアウトの時間(秒単位)
読み取り専用
- トランザクション内の処理が読み取り専用かどうか
ロールバック対象例外
- どの例外の時にロールバックするか設定できる。デフォルトでは実行時例外の場合。検査例外が投げられてもロールバックされない明示的トランザクションの場合はExceptionでもロールバックされました。
  - 検査例外が投げられてもロールバックされない明示的トランザクションの場合はExceptionでもロールバックされました。
  - 明示的トランザクションの場合はExceptionでもロールバックされました。
コミット対象例外
- どの例外の時にコミットするか設定できる。デフォルトでは検査例外が投げられた際はコミットが行われる。

明示的トランザクションを利用する

前提知識が多かったですが、ようやく実装に入りたいと思います。今回はSpringBoot環境で実装を行っていきます。

全体のソースは以下のブランチにあげております。

https://github.com/jirentaicho/springboot-transaction-sample/tree/dev01

以下のようなテーブルを利用します

処理説明

acceptを登録します
- accpetで登録するstockをstocksから取得します
- stockのcountをacceptのcountだけ減算しますacceptのcountは100を想定しています
- stockのcountがマイナス値の場合は例外になりますstockの件数が100以下なら例外になります
- acceptレコードの追加処理を行います
- stockレコードの更新処理を行います。
  - acceptのcountは100を想定しています
  - stockの件数が100以下なら例外になります

@Service
public class AcceptServiceImpl implements AcceptService {

    @Autowired
    private AcceptRepository acceptRepository;

    @Autowired
    private ItemRepository itemRepository;

    @Autowired
    private StockRepository stockRepository;

    @Autowired
    private PlatformTransactionManager txManager;

    @Override
    public void createAccept(AcceptController.RegistAcceptModel model) throws Exception {
        //定義情報を作成します
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
        def.setIsolationLevel(TransactionDefinition.ISOLATION_DEFAULT);
        def.setTimeout(10);
        def.setReadOnly(false);
        // トランザクションを開始します
        TransactionStatus status = txManager.getTransaction(def);
        try{
            // ドメインモデルの作成
            Accept accept = new Accept(model.itemId,model.customerName,model.count);
            // 受注の登録をする
            // わかりやすくロールバックを確認するためここで永続化します
            this.acceptRepository.register(accept);

            // 在庫の取得
            Stock stock = this.stockRepository.findStockByItemId(accept.getItemId());

            // 在庫を減らす(本当の業務なら実在庫を減らすことはせず予定在庫を減らすなど)
            stock.subCount(accept.getCount());
            // 在庫の整合性を確認する
            if(stock.isMinus()){
                // 適当な例外投げてます
                throw new RuntimeException();
            }
            // 在庫の更新をする
            this.stockRepository.save(stock);
        } catch (RuntimeException e){
            // 例外が発生した時にロールバックする
            txManager.rollback(status);
            throw e;
        }
        // コミットする
        txManager.commit(status);
    }
}

PlatformTransactionManagerをインジェクションすることでトランザクションマネージャを利用できます
new DefaultTransactionDefinition();
- 定義情報を作成して、定義情報を設定していきます
txManager.getTransaction(def);
- 定義情報を元にトランザクションを取得(開始)します

TransactionTemplateを利用する

もう一つのやり方としてTransactionTemplateを利用する方法があります。

ソースコードは以下のブランチにあげています。

https://github.com/jirentaicho/springboot-transaction-sample/tree/dev-template

こちらはcommitやrollbackのメソッドの呼び出しを隠蔽してくれます。

@Service
public class AcceptServiceImpl implements AcceptService {

    @Autowired
    private AcceptRepository acceptRepository;

    @Autowired
    private ItemRepository itemRepository;

    @Autowired
    private StockRepository stockRepository;

    @Autowired
    private PlatformTransactionManager txManager;

    @Override
    public void createAccept(AcceptController.RegistAcceptModel model) throws Exception {

        TransactionTemplate tm = new TransactionTemplate(txManager);
        tm.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
        tm.setIsolationLevel(TransactionDefinition.ISOLATION_DEFAULT);
        tm.setTimeout(10);
        tm.setReadOnly(false);
        tm.execute((status) -> {
            // ドメインモデルの作成
            Accept accept = new Accept(model.itemId,model.customerName,model.count);
            // 受注の登録をする
            // わかりやすくロールバックを確認するためここで永続化します
            this.acceptRepository.register(accept);
            // 在庫の取得
            Stock stock = this.stockRepository.findStockByItemId(accept.getItemId());
            // 在庫を減らす(本当の業務なら実在庫を減らすことはせず予定在庫を減らすなど)
            stock.subCount(accept.getCount());
            // 在庫の整合性を確認する
            if(stock.isMinus()){
                // 適当な例外投げてます
                throw new RuntimeException();
            }
            // 在庫の更新をする
            this.stockRepository.save(stock);
            return DataAccessStatus.SUCCESS;
        });
    }

    /**
     * return nullの代用
     */
    public static enum DataAccessStatus{
        SUCCESS,
        ERROR
    }
}

TransactionTemplateを作成する際にトランザクションマネージャを渡しています
execute内にトランザクション内の処理を記載すれば、自動的にロールバックもコミットもしてくれます。
executeメソッドの引数に渡すラムダ式は、戻り値が特にない場合はreturn null;をしている例もありましたが、あまり好きじゃないので形式的なenumを返しています。
TransactionCallbackWithoutResultをオーバーライドした戻り値なしのケースも作成できます。
- ただ、今回の例ではスコープの問題等で実装していません。
- ラムダを使った方が圧倒的に良いです。

伝搬属性の確認

次に伝搬属性について見ていきます。あまり無いケースかと思いますが、サービスからサービスを呼出して無理矢理トランザクション内からトランザクション処理を呼び出します。

REQUIRES_NEW

このパターンは新しいトランザクションを開始するパターンです。

全体のソースコードは以下のブランチにあげております。

https://github.com/jirentaicho/springboot-transaction-sample/tree/req_new

@Override
    public void createAccept(AcceptController.RegistAcceptModel model) throws Exception {

        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
        def.setIsolationLevel(TransactionDefinition.ISOLATION_DEFAULT);
        def.setTimeout(10);
        def.setReadOnly(false);
        TransactionStatus status = txManager.getTransaction(def);
        try{
            // 別のトランザクション処理の呼出しを行う
            this.stockService.update();

            // ドメインモデルの作成
            Accept accept = new Accept(model.itemId,model.customerName,model.count);
            // 受注の登録をする
            // わかりやすくロールバックを確認するためここで永続化します
            this.acceptRepository.register(accept);
            // 在庫の取得
            Stock stock = this.stockRepository.findStockByItemId(accept.getItemId());
            // 在庫を減らす(本当の業務なら実在庫を減らすことはせず予定在庫を減らすなど)
            stock.subCount(accept.getCount());
            // 在庫の整合性を確認する
            if(stock.isMinus()){
                // 適当な例外投げてます
                throw new RuntimeException();
            }
            // 在庫の更新をする
            this.stockRepository.save(stock);
        } catch (RuntimeException e){
            txManager.rollback(status);
            throw e;
        }
        txManager.commit(status);
    }

先ほどのトランザクションから別のトランザクション処理を呼びます
別のトランザクションの処理が完了後、呼び出し元のトランザクションでロールバックを起こします。

@Service
public class StockServiceImpl implements StockService {

    @Autowired
    private StockRepository stockRepository;

    @Autowired
    private PlatformTransactionManager txManager;

    @Override
    public void update() {
        //　あくまでトランザクション確認用のメソッドです。
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW); //新規トランザクションを開始
        def.setIsolationLevel(TransactionDefinition.ISOLATION_DEFAULT);
        def.setTimeout(10);
        def.setReadOnly(false);
        TransactionStatus status = txManager.getTransaction(def);
        try{
            Stock stock = this.stockRepository.findStockByItemId(2);
            stock.subCount(10);
            stockRepository.save(stock);
        } catch (RuntimeException e){
            txManager.rollback(status);
            throw e;
        }
        txManager.commit(status);
    }
}

id=2のstockのcountを10減算して更新します

現在のデータベースのレコードは以下のようになっています。

処理を実行します

呼び出し元のトランザクションでロールバックしているのに、countが10減っています。

これはdef.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW)として、呼び出し元のトランザクションに参加せず、新しいトランザクションを開始しているためです。

PROPAGATION_REQUIRED

全体のソースを以下のブランチにあげております

https://github.com/jirentaicho/springboot-transaction-sample/tree/required※チェリーピックしているので他のコミットコメントが入ってます。

REQUIRES_NEWで行ったことと同じことを、PROPAGATION_REQUIREDにして実行します。こっちは呼び出し元のトランザクションに参加しますので、呼び出し元でロールバックされるとデータのコミットが行われません。

@Override
    public void update() {
        //　あくまでトランザクション確認用のメソッドです。
        DefaultTransactionDefinition def = new DefaultTransactionDefinition();
        def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); //既存トランザクションに参加
        def.setIsolationLevel(TransactionDefinition.ISOLATION_DEFAULT);
        def.setTimeout(10);
        def.setReadOnly(false);
        TransactionStatus status = txManager.getTransaction(def);
        try{
            Stock stock = this.stockRepository.findStockByItemId(2);
            stock.subCount(10);
            stockRepository.save(stock);
        } catch (RuntimeException e){
            txManager.rollback(status);
            throw e;
        }
        txManager.commit(status);
    }

データベースの状態も同じです

実行します

呼び出し元のトランザクションでロールバックが呼ばれると、レコードの更新は行われませんでした。

宣言的トランザクションの利用

ソースは以下のブランチにあげています

https://github.com/jirentaicho/springboot-transaction-sample/tree/dev02

@Service
public class AcceptServiceImpl implements AcceptService {

    @Autowired
    private AcceptRepository acceptRepository;

    @Autowired
    private ItemRepository itemRepository;

    @Autowired
    private StockRepository stockRepository;

    @Override
    @Transactional(
            propagation = Propagation.REQUIRED,
            isolation = Isolation.DEFAULT,
            timeout = 10,
            readOnly = false
    )
    public void createAccept(AcceptController.RegistAcceptModel model) throws Exception {
        // ドメインモデルの作成
        Accept accept = new Accept(model.itemId, model.customerName, model.count);
        // 受注の登録をする
        // わかりやすくロールバックを確認するためここで永続化します
        this.acceptRepository.register(accept);

        // 在庫の取得
        Stock stock = this.stockRepository.findStockByItemId(accept.getItemId());

        // 在庫を減らす(本当の業務なら実在庫を減らすことはせず予定在庫を減らすなど)
        stock.subCount(accept.getCount());
        // 在庫の整合性を確認する
        if (stock.isMinus()) {
            // 適当な例外投げてます
            throw new RuntimeException();
        }
        // 在庫の更新をする
        this.stockRepository.save(stock);
    }
}

アノテーションを利用したトランザクションの場合はコードがスッキリします
定義情報は@Transactionalアノテーションに付与できます
throw new Exception();のように例外を起こした場合はロールバックされません。
- RuntimeException、およびそのサブクラスならロールバックされます

その他

No EntityManager with actual transaction available for current thread – cannot reliably process ‘persist’ call

トランザクションが開始されていない場合に起こりますので、トランザクションを開始する必要があります。

メモ程度ですが、伝搬属性PROPAGATION_REQUIRES_NEWと.PROPAGATION_NESTEDのコード上の違いについて

getTransactionを呼出したときに、おそらくここに流れる

if (isExistingTransaction(transaction)) {
	// Existing transaction found -> check propagation behavior to find out how to behave.
	return handleExistingTransaction(def, transaction, debugEnabled);
}

このhandleExistingTransactionメソッドで処理の振り分けをしている

if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_REQUIRES_NEW) {
	if (debugEnabled) {
		logger.debug("Suspending current transaction, creating new transaction with name [" +
				definition.getName() + "]");
	}
	SuspendedResourcesHolder suspendedResources = suspend(transaction);
	try {
		return startTransaction(definition, transaction, debugEnabled, suspendedResources);
	}
	catch (RuntimeException | Error beginEx) {
		resumeAfterBeginException(transaction, suspendedResources, beginEx);
		throw beginEx;
	}
}

if (definition.getPropagationBehavior() == TransactionDefinition.PROPAGATION_NESTED) {
	if (!isNestedTransactionAllowed()) {
		throw new NestedTransactionNotSupportedException(
				"Transaction manager does not allow nested transactions by default - " +
				"specify 'nestedTransactionAllowed' property with value 'true'");
	}
	if (debugEnabled) {
		logger.debug("Creating nested transaction with name [" + definition.getName() + "]");
	}
	if (useSavepointForNestedTransaction()) {
		// Create savepoint within existing Spring-managed transaction,
		// through the SavepointManager API implemented by TransactionStatus.
		// Usually uses JDBC 3.0 savepoints. Never activates Spring synchronization.
		DefaultTransactionStatus status =
				prepareTransactionStatus(definition, transaction, false, false, debugEnabled, null);
		status.createAndHoldSavepoint();
		return status;
	}
	else {
		// Nested transaction through nested begin and commit/rollback calls.
		// Usually only for JTA: Spring synchronization might get activated here
		// in case of a pre-existing JTA transaction.
		return startTransaction(definition, transaction, debugEnabled, null);
	}
}

参考

［改訂新版］Spring入門 ――Javaフレームワーク・より良い設計とアーキテクチャ
- この本、すごく気に入ってます。と、ミサカは遠回しにオススメします。

トランザクションマネージャについて深く見る | Spring