2021-06-04

ブログを書き始めてから、10年経ちました

雑記

なんと

このブログですが、書き始めてから10年経っていたようです。

最初に書いたのは2011年5月14日で、「今日から開設。」とまったくやる気がなさそうな1本目から始まっているのですが。

続けて10年経ったということに、今年になって「どれくらい続けてるの？」と聞かれて気づいてしまいました。

たぶん、聞かれてなかったら気づいてないですね。

このブログでは、実際の自分の勉強の記録以外ほとんど書いてきていないのですが、こういう区切りっぽい年くらい
たまにはいいかなぁということで。

振り返りを兼ねて、つらつらと書いてみましょう。自分が「どうしてだっけ？」というのを考えながら書いています。

もう数年経った時に、自分で見返したらどう思うでしょうね？

ブログを始めた理由

自分の勉強のために始めました。

当時、本を読んだり、本やWebを見ながらコードを書いていても、どうも身につかないことに悩んでいて。
文章で書いた方が覚えるだろう、という効果を狙って始めたのがきっかけです。

想定対象読者

対象読者は、自分自身です。

ごく稀に、読み手の存在を意識して書く記事もありますが（最近やってないですが、Advent Calendarなど）、基本的には
自分の勉強のため、未来の自分が見て読み返して、思い出せるために書いています。

1回ちゃんと書いておけば、あとで見ても書いた当時にどういうことをやったのか、意外と思い出せるものだったりします。

とはいえ、たまに書いたこと自体を忘れていて、同じような記事を書いてしまうこともありましたけどね。

けっこう冗長感のあるタイトルのものが多いと思うのですが、これはキーワードで自分が検索しやすくするためです。

自分以外の人が読むことはほとんど気にしていなくて、「こんなブログの記事でも、読めるようなら、なにか役に立つようで
あればどうぞ」といったスタンスでやっています。これは、このブログを始めた時からずっとそう思っています。

なので、「結論をわかりやすくまとめる」といったことはほとんどしていなくて、「これをやろう」、「そしてこうだった」
ということを淡々と書いています。

当初から、「こんなブログを見る奇特な人なんていないだろう」と思って書いているんですけどね。
それは、記事へのアクセス数からも言えると思うのですが。

そういえば、はてなブログに移行してから、読者の増え方が上がった気がします。どうしてなんでしょう？

なんで"CLOVER"？

"CLOVER"自体に意味は込めていません。

このブログの名前はある集合から音の響きで選んだもので、時々変えていたのですが、"CLOVER"に変えた後に意外と
見られていることがわかってしまい、変えるに変えられなくなって今に至ります。

現時点で、書いた記事数

単純な数なら、10年で1,432。

ほんの数行、みたいなものもありますけど。

他と比較することも、したいとも思ったことがないので、これが多い、少ないはよくわかりません。

続けている理由

自分の勉強のために書いているので、完全に趣味です。

やることがない時に、「そういえば、これ試してみたいな」くらいの動機で書いていることが多いです。

他の予定があったら、ふつうにそちらを優先してます。

ノルマとか

月に1回投稿すること。これだけです。

書くネタの決め方

このあたりから、「勉強したいリスト」を作って、ある程度優先順位をつけて決めています。

年末の振り返りで年内にやったことと、来年に勉強してみたいことをリストアップしてみたもの
日常の目に入った情報から、興味があったもの
仕事で触れるもので、自分の興味と合致したもの

そのリストに沿って必ずやっているかというとそうでもなく、気づくと「けっこう違うことやっているな」ということも
多々あります。

ここ数年は仕事で扱うものについても書く割合が増えている気がしますが、仕事で使うものであっても
そもそも自分の興味のないものでないと、このブログには登場しません。

あと、このブログに書いている内容は、ほとんどがいわゆる「やってみた」という内容なので、キャッチーさが
ほぼありません。興味のある内容を試していっている履歴なので、まあ、そうなりますよね、と。
記事が注目されない一因でもある気はしますが。

この傾向が変わることは、ないと思います。今のところ、そういう感じになることはないかなぁと。

やりたいネタは、十分に扱えてる？

遊んでみたいこと、試してみたいことに追いつかないことが増えましたね。

他のものを扱っていたり、優先度を入れ替えたりした結果、時間が過ぎてしまってそのまま見送ってしまうものが
けっこうあります。

公式のGetting Startedとか、他の人が同じような情報を書いてることも書いているような？意味ないのでは？

ふつうに書いています。

他の方が書いていたとしても、自分で確認して、自分の言葉でこのブログで書けるくらいに理解してみる、納得してみる、が
このブログを書いている理由にもなっていますし。

それに、他の方の理解したことと、自分が確認して理解したことは同じではないと思いますし、どこか違いがあるでしょう。

もしかしたらまったく同じかもしれませんが、それを無意味だとは思いません。

他の方の記事を書き写しているようなら意味はないと思いますが、アクセス数を稼ぎたいわけでもないですし。

アクセスの傾向とか、よく読まれている記事とか？

平日にアクセスが多く、休みの日はかなり下がります。

Linuxに関するものが多く見られている傾向にありますが、すごく突出したものはありませんし（アクセス解析でも1位が3％とか）、
はてブもあまりつきません。

なので、なにがよく読まれているとか自分でもよくわかりません。いろんなページに散らばっているんだろうな、とは
思っています。

なお、はてなブログに移行するまでアクセス解析を見たことがなかったので、そこで始めてアクセス傾向を知りましたし、
はてなダイアリーの頃にどうだったのかはまったくわかりません。

10年書いていて、書き方が変わったとかある？

書き始めのころからすると、記事の構成がだいぶ変わりました。

大きく変わったのは、確認した時の条件、環境と、情報源の残し方ですね。

自分が書き始めた頃と比べると、情報の陳腐化する速度が早まったこともあって、ここ数年は

ライブラリやミドルウェアを使う場合は、どのバージョンについての話なのかを明記する
前提となる環境の情報を明記する

ということを、書きすぎない、ジャマにならない程度に書くことにしています。

参照する情報の引用元については、

公式のドキュメントや、ソースコードリポジトリ

にするように強く意識しています。

この時、可能な限りドキュメントもソースコードも、参照する時には使っているバージョンの指しているURLを使用するように
しています。

たまにドキュメントは latest しかなくて諦めるとか、リポジトリにタグがない時は仕方がないのでコミットハッシュを指すとか
困ることはありますが、可能な限り記事を書いた時に使ったバージョンを追えるように注意しています。

このあたりは書き始めた当初は緩くて、バージョンを明記していないとか、公式以外のブログ記事などをそのまま
参考先としていたりしましたが。

今は、公式の情報を必ず確認するようにしています。

たまに、公式のドキュメントに書かれていないかったり、記述が十分にない情報について足元をすくわれたりして、
「もうちょっと他も調べておけばよかったかも」と思うこともあるのですが。

最初に見つけたのが公式以外の情報でも、それが公式のドキュメントに載っているかどうかは確認するようにしています。

特に書いた時の条件や環境を書き残すことにしてから構成を見直すようになり、これらに加えて「そもそもなんでこの記事
書いたの？」というのを小さなことでも書くようにしたのが今の書き方です。

あとは、書いていて「これも気になる」と思ったことを深追いして、記事が長めになることが増えた気がします…。

他のブログサービスや、プラットフォームに移らないのは？

このブログは、はてなダイアリーで始めて、今は、はてなブログとして利用させていただいているわけですが。

ブログを書くことで自分のブランディングをしているわけでもないですし、記事を書いて注目を集めたいというわけでも
ないので、移る理由がなく。

なにより、自分の勉強の記録として書いているだけなので、もし移るとすれば記事ごと全部移らないと意味がありません。
それも手間ですしね。

気ままに、書きたいものが自由に書ける場所であればそれでいいです。

とはいえ、他の場所でこういう技術系のブログ、記事を書きたくない、というわけでもありません。

ブログを続けてきて良かった？

後悔みたいなものは、まったくしていなくて。

仕事に直接役に立ってますか？という話だとそうでもないものは多いですが、情報の調べ方、実際に動かして確認してみる、
という繰り返しの経験はそれなりに意味があるんじゃないかな、と思っています。

このブログをきっかけに、知り合いになった方もいらっしゃいますしね。

それに、幸い？記事が注目を集めることがまったくないので、非難？のようなものも受けてきませんでしたし。

まあ、まったくなにもないかというとそんなことはなく、微妙に思うコメントがつくとか、実際に見た人から「知ってることしか
書かれていない」とか言われたこととかもあったりしますが。

ごく少数ですし、「見なくていいですよ？」としか思わないので。

ブログに登場していないけれど、勉強してみたいものは？

このブログでは、ある条件に当てはまったものは、興味があってもテーマとしては取り扱わないことにしています。

それに当てはまるひとつとして、このブログにはクラウドが登場しません。
クラウド以外のものについては扱っていないことを気にしていなかったのですが、クラウドについてはそれでいいのかな？
とは時々思っています。

でも、今後も登場することはないんだろうな、とも思っています。

今後はどうする？

変わらず、マイペースに続けると思いますよ。

これからも見る方がいらっしゃるようであれば、なにか役に立つものがあれば良いな、と思います。

2021-05-30

Spring Frameworkで、REQUIREDな伝播レベルのトランザクションがネストした時の例外の扱いを確認する

Spring

これは、なにをしたくて書いたもの？

Spring Frameworkを使っていると、トランザクション管理を@Transactionalアノテーションを使って宣言的に書いていることが
多いと思います。

@Transactionalを使った場合、例外（デフォルトではRuntimeExceptionのサブクラス）がスローされた時にロールバックされる
ことになっています。ここで、@Transactionalアノテーションが付与されたメソッドがネストし、かつ途中で例外を
捕捉した場合にどういう挙動になるのか、確認してみたいなと思いまして。

トランザクションの伝播については、PROPAGATION_REQUIREDを主な対象にしています。

Springの宣言的トランザクションとトランザクションの伝播

Springの宣言的トランザクションに関するドキュメントとしては、こちらですね。

Declarative Transaction Management

また、@Transactionalアノテーションについては、こちらに記載されています。

Using @Transactional

ここで、トランザクションの伝播に関するドキュメントを読んでみます。

Transaction Propagation

最初に疑問に書いたことの答えが、実はここに書いています。

Understanding PROPAGATION_REQUIRED

PROPAGATION_REQUIREDを使ったトランザクションがネストし、内側のトランザクションのロールバックが確定した場合の
ことが書いてあります。

When the propagation setting is PROPAGATION_REQUIRED, a logical transaction scope is created for each method upon which the setting is applied. Each such logical transaction scope can determine rollback-only status individually, with an outer transaction scope being logically independent from the inner transaction scope. In the case of standard PROPAGATION_REQUIRED behavior, all these scopes are mapped to the same physical transaction. So a rollback-only marker set in the inner transaction scope does affect the outer transaction’s chance to actually commit.

However, in the case where an inner transaction scope sets the rollback-only marker, the outer transaction has not decided on the rollback itself, so the rollback (silently triggered by the inner transaction scope) is unexpected. A corresponding UnexpectedRollbackException is thrown at that point. This is expected behavior so that the caller of a transaction can never be misled to assume that a commit was performed when it really was not. So, if an inner transaction (of which the outer caller is not aware) silently marks a transaction as rollback-only, the outer caller still calls commit. The outer caller needs to receive an UnexpectedRollbackException to indicate clearly that a rollback was performed instead.

つまり、内側のトランザクションのロールバックが確定していると外側のトランザクションはUnexpectedRollbackExceptionを
スローする、ということになりそうです。

内側のトランザクションを独立させたい場合は、PROPAGATION_REQUIRES_NEWを使うわけですね。

Understanding PROPAGATION_REQUIRES_NEW

今回は、ここまで含めて確認してみようかな、と思います。

環境

今回の環境は、こちらです。

$ java --version
openjdk 11.0.11 2021-04-20
OpenJDK Runtime Environment (build 11.0.11+9-Ubuntu-0ubuntu2.20.04)
OpenJDK 64-Bit Server VM (build 11.0.11+9-Ubuntu-0ubuntu2.20.04, mixed mode, sharing)


$ mvn --version
Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)
Maven home: $HOME/.sdkman/candidates/maven/current
Java version: 11.0.11, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64
Default locale: ja_JP, platform encoding: UTF-8
OS name: "linux", version: "5.4.0-73-generic", arch: "amd64", family: "unix"

データベースはMySQL 8.0.25を使い、172.17.0.2で動作しているものとします。

Spring Bootプロジェクトを作成する

最初に、Spring Bootプロジェクトを作成します。Spring Bootのバージョンは2.5.0で、依存関係にはjdbcとmysqlを加えます。

$ curl -s https://start.spring.io/starter.tgz \
  -d bootVersion=2.5.0 \
  -d javaVersion=11 \
  -d name=transactional-nested-required \
  -d groupId=org.littlewings \
  -d artifactId=transactional-nested-required \
  -d version=0.0.1-SNAPSHOT \
  -d packageName=org.littlewings.spring.jdbc \
  -d dependencies=jdbc,mysql \
  -d baseDir=transactional-nested-required | tar zxvf -


$ cd transactional-nested-required
$ find src -name '*.java' | xargs rm

生成されたJava ソースコードは削除。

Maven依存関係などは、こんな感じです。

 <properties>
        <java.version>11</java.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-jdbc</artifactId>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>

確認はテストコードで行おうと思いますが、@SpringBootApplicationアノテーションを付与したクラスは作成して
おきます。

src/main/java/org/littlewings/spring/jdbc/App.java

package org.littlewings.spring.jdbc;

import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class App {
}

application.propertiesは、こんな設定にしておきました。

src/main/resources/application.properties

spring.datasource.url=jdbc:mysql://172.17.0.2:3306/practice?characterEncoding=utf-8&characterSetResults=utf-8
spring.datasource.username=kazuhira
spring.datasource.password=password

お題

@Transactionalアノテーションを付与したメソッドを持つクラスを作成し、ふつうに処理を完了させたり、例外をスローして
キャッチしたりしなかったり…といくつかバリエーションをつけて確認してみましょう。

トランザクションの伝播はPROPAGATION_REQUIRESから始め、PROPAGATION_REQUIRES_NEWも織り交ぜて
いくようにします。

テストコードの雛形

まずはテストコードの雛形を作成しましょう。こんな感じにしました。

src/test/java/org/littlewings/spring/jdbc/TransactionalTest.java

package org.littlewings.spring.jdbc;

import java.util.List;

import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.transaction.UnexpectedRollbackException;

import static org.assertj.core.api.Assertions.assertThat;
import static org.assertj.core.api.Assertions.assertThatThrownBy;

@SpringBootTest
public class TransactionalTest {
    @Autowired
    JdbcTemplate jdbcTemplate;

    @BeforeEach
    public void createTable() {
        jdbcTemplate.execute("drop table if exists sample");

        jdbcTemplate.execute("create table sample(word varchar(25));");
    }

    // ここに、テストを書く
}

テストごとに、テーブルをDROP ＆ CREATEします。

Serviceクラス

今回は、Serviceクラスを2つ用意します。それぞれ、@Transactionalアノテーションを付与したメソッドを持ち、
外側のトランザクション、内側のトランザクションを表現します。

外側に該当するものは、こちら。JdbcTemplateと、内側のServiceクラスを使用します。

src/main/java/org/littlewings/spring/jdbc/MyService.java

package org.littlewings.spring.jdbc;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;

@Service
public class MyService {
    Logger logger = LoggerFactory.getLogger(MyService.class);

    JdbcTemplate jdbcTemplate;

    NestedService nestedService;

    public MyService(JdbcTemplate jdbcTemplate, NestedService nestedService) {
        this.jdbcTemplate = jdbcTemplate;
        this.nestedService = nestedService;
    }

    // メソッドを書く
}

MyServiceクラスから呼び出されるのは、こちら。同じく、JdbcTemplateを使用します。

src/main/java/org/littlewings/spring/jdbc/NestedService.java

package org.littlewings.spring.jdbc;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Propagation;
import org.springframework.transaction.annotation.Transactional;

@Service
public class NestedService {
    Logger logger = LoggerFactory.getLogger(NestedService.class);

    JdbcTemplate jdbcTemplate;

    public NestedService(JdbcTemplate jdbcTemplate) {
        this.jdbcTemplate = jdbcTemplate;
    }

    // メソッドを書く
}

これらのクラスとテストコードを使って、確認してきましょう。

テストコード側では、上記のMyServiceクラスを使用します。

@SpringBootTest
public class TransactionalTest {
    @Autowired
    JdbcTemplate jdbcTemplate;

    @BeforeEach
    public void createTable() {
        jdbcTemplate.execute("drop table if exists sample");

        jdbcTemplate.execute("create table sample(word varchar(25));");
    }

    @Autowired
    MyService myService;

ここから先は、MyService、NestedService、テストコードの順でいろいろ書いて確認していきます。

PROPAGATION_REQUIRES

では、確認していきましょう。

コミットする

まずはふつうにトランザクションが完了する（＝コミットする）パターン。指定されたwordを登録するinsert文を実行して、
そのwordを二重にして次のServiceクラスを呼び出します。

@Service
public class MyService {

    @Transactional
    public int insertRequired(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequired(word + " " + word);
    }

}

クラスの定義は、抜粋して書いていきます。

呼び出し先。

@Service
public class NestedService {

    @Transactional
    public int insertRequired(String word) {
        return jdbcTemplate.update("insert into sample(word) values(?)", word);
    }

}

どちらも更新件数を返すので、両方の更新がうまくいった場合は戻り値が2になりますね。

テストコード。データが登録されているのが確認できます。

    @Test
    public void transactionalNormally() {
        assertThat(myService.insertRequired("Hello!!")).isEqualTo(2);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!", "Hello!! Hello!!"));
    }

ロールバックする

次は、ロールバックするパターン。

外側のServiceクラスはふつうですが

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedThrown(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredAndThrown(word + " " + word);
    }

}

内側のServiceクラスでは例外をスローします。

@Service
public class NestedService {

    @Transactional
    public int insertRequiredAndThrown(String word) {
        jdbcTemplate.update("insert into sample(word) values(?)", word);

        throw new RuntimeException("Oops!!");
    }

}

テストコード側。ロールバックですね。

    @Test
    public void transactionalNestedFailed() {
        assertThatThrownBy(() -> myService.insertRequiredAndNestedThrown("Hello!!"))
                .isInstanceOf(RuntimeException.class)
                .hasMessage("Oops!!");

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEmpty();
    }

内側のServiceクラスが例外をスローし、外側のServiceクラス内で捕捉する

続いては、内側のServiceクラスのメソッドが例外をスローして、外側のServiceクラスでその例外を補足するパターン。

つまり、外側のServiceクラスはこんな感じです。

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedThrownAndCatch(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        try {
            nestedService.insertRequiredAndThrown(word + " " + word);
        } catch (RuntimeException e) {
            logger.error("insert failed", e);
        }

        return result;
    }

}

内側のServiceクラスは、先ほどと同じです。

@Service
public class NestedService {

    @Transactional
    public int insertRequiredAndThrown(String word) {
        jdbcTemplate.update("insert into sample(word) values(?)", word);

        throw new RuntimeException("Oops!!");
    }

}

テストコードは外側のServiceクラスから例外がスローされない…と思いきや、UnexpectedRollbackExceptionがスローされる
ことになります。

こんなことを言われつつ。

Transaction rolled back because it has been marked as rollback-only

    @Test
    public void transactionalNestedFailedAndCatch() {
        assertThatThrownBy(() -> myService.insertRequiredAndNestedThrownAndCatch("Hello!!"))
                .isInstanceOf(UnexpectedRollbackException.class)
                .hasMessage("Transaction rolled back because it has been marked as rollback-only");

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEmpty();
    }

ドキュメント通りですね。

内側のServiceクラスで例外は発生するものの、メソッドを例外で抜けない

なにを言っているかというと、内側のServiceクラスで例外は発生するものの、トランザクションの境界となるメソッドは
例外で脱出しない、と。

外側のServiceクラスは、こんな感じです。

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedIgnoreFailed(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredAndIgnoreFailed(word + " " + word);
    }

}

内側のServiceクラスは誤ったSQL文を実行させて例外が発生しますが、メソッド自体は例外では抜けません。

@Service
public class NestedService {

    @Transactional
    public int insertRequiredAndIgnoreFailed(String word) {
        try {
            // 構文誤りで実行に失敗するSQL
            jdbcTemplate.update("insert into sample(word) v(?)", word);
        } catch (RuntimeException e) {
            logger.error("sql error", e);
        }

        return 0;
    }

}

テストコードでは、外側のServiceクラスの処理結果だけが反映（＝コミット）されていることが確認できます。

    @Test
    public void transactionalNestedIgnoreFailed() {
        assertThat(myService.insertRequiredAndNestedIgnoreFailed("Hello!!")).isEqualTo(1);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!"));
    }

予想できる話ではありますが、トランザクションの境界を例外で抜けていませんからね。

つまり、トランザクションの伝播がPROPAGATION_REQUIREDの積み重ねとなりえる場合は、中途半端なところで
例外を捕まえずにトランザクションの境界外で捕捉するか、トランザクションの境界を跨がないうちに捕捉すること、という
感じにした方が良さそうですね。

ソースコードから確認する

このあたりの動作を、ソースコード上でも確認してみましょう。

トランザクション境界となるメソッドを例外で抜けた時点で、ロールバックのマークが行われます。

https://github.com/spring-projects/spring-framework/blob/v5.3.7/spring-tx/src/main/java/org/springframework/transaction/support/AbstractPlatformTransactionManager.java#L844

ResourceHolderSupportでのrollbackOnlyがtrueに設定されるのが、そのマークですね。

https://github.com/spring-projects/spring-framework/blob/v5.3.7/spring-tx/src/main/java/org/springframework/transaction/support/ResourceHolderSupport.java#L67-L69

この状態になると、外側のトランザクション境界をコミットしようとしたタイミングで、ロールバックを行うようにマークされて
いることが検出されます。

https://github.com/spring-projects/spring-framework/blob/v5.3.7/spring-tx/src/main/java/org/springframework/transaction/support/AbstractPlatformTransactionManager.java#L703-L709

そして、UnexpectedRollbackExceptionがスローされます、と。

https://github.com/spring-projects/spring-framework/blob/v5.3.7/spring-tx/src/main/java/org/springframework/transaction/support/AbstractPlatformTransactionManager.java#L869-L872

こちらが、ソースコード上での確認ですね。

あとは、もう少しバリエーションを確認してみましょう。

PROPAGATION_REQUIRESとPROPAGATION_REQUIRES_NEWの組み合わせ

今度は、外側をPROPAGATION_REQUIRES、内側をPROPAGATION_REQUIRES_NEWにしてみます。

外側と内側で、トランザクションが別になりますね。

コミットする

外側のServiceクラス。

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedNew(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredNew(word + " " + word);
    }

}

内側のServiceクラス。トランザクションの伝播レベルが、REQUIRES_NEWです。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNew(String word) {
        return jdbcTemplate.update("insert into sample(word) values(?)", word);
    }

}

とはいえ、コミットするので結果はまあふつうです。

    @Test
    public void transactionalNormallyNestedNew() {
        assertThat(myService.insertRequiredAndNestedNew("Hello!!")).isEqualTo(2);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!", "Hello!! Hello!!"));
    }

ロールバックする

続いて、ロールバック。こちらも変わったことはありません。

外側のServiceクラス。

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedNewThrown(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredNewAndThrown(word + " " + word);
    }

}

内側のServiceクラス。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndThrown(String word) {
        jdbcTemplate.update("insert into sample(word) values(?)", word);

        throw new RuntimeException("Oops!!");
    }

}

両方のメソッドを例外で抜けるので、ロールバックします。

    @Test
    public void transactionalNestedNewFailed() {
        assertThatThrownBy(() -> myService.insertRequiredAndNestedNewThrown("Hello!!"))
                .isInstanceOf(RuntimeException.class)
                .hasMessage("Oops!!");

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEmpty();
    }

内側のServiceクラスが例外をスローし、外側のServiceクラス内で捕捉する

こちらは、PROPAGATION_REQUIREDの時と変化があります。

外側のServiceクラス。内側のServiceクラスがスローした例外を捕捉します。

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedNewThrownAndCatch(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        try {
            nestedService.insertRequiredNewAndThrown(word + " " + word);
        } catch (RuntimeException e) {
            logger.error("insert failed", e);
        }

        return result;
    }

}

内側のServiceクラスは、先ほどと同じです。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndThrown(String word) {
        jdbcTemplate.update("insert into sample(word) values(?)", word);

        throw new RuntimeException("Oops!!");
    }

}

テストコード。PROPAGATION_REQUIREDがネストしている時とは異なり、UnexpectedRollbackExceptionはスローされず
外側のトランザクションはコミットされます。

    @Test
    public void transactionalNestedNewFailedAndCatch() {
        assertThat(myService.insertRequiredAndNestedNewThrownAndCatch("Hello!!")).isEqualTo(1);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!"));  // 例外にならない
    }

別々のトランザクションになっているので、こうなりますよね。

内側のServiceクラスで例外は発生するものの、メソッドを例外で抜けない

こちらも試してみます。

外側のServiceクラス。

@Service
public class MyService {

    @Transactional
    public int insertRequiredAndNestedNewIgnoreFailed(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredNewAndIgnoreFailed(word + " " + word);
    }

}

内側のServiceクラス。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndIgnoreFailed(String word) {
        try {
            // 構文誤りで実行に失敗するSQL
            jdbcTemplate.update("insert into sample(word) v(?)", word);
        } catch (RuntimeException e) {
            logger.error("sql error", e);
        }

        return 0;
    }

}

テストコード。こちらについては、それぞれ別のトランザクションがコミットされただけ、となります。

    @Test
    public void transactionalNestedNewIgnoreFailed() {
        assertThat(myService.insertRequiredAndNestedNewIgnoreFailed("Hello!!")).isEqualTo(1);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!"));
    }

そりゃあ、そうなりますよね、と。

両方ともPROPAGATION_REQUIRES_NEWにする

今回の確認方法でこれをやる意味はない気がしますが、網羅的な意味では一応…ということで。

ソースコードと結果だけ載せます。

PROPAGATION_REQUIRES、PROPAGATION_REQUIRES_NEWの組み合わせと同じ結果になります。それぞれが
独立することを明示しているだけなので。

コミットする

外側のServiceクラス。

@Service
public class MyService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndNestedNew(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredNew(word + " " + word);
    }

}

内側のServiceクラス。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNew(String word) {
        return jdbcTemplate.update("insert into sample(word) values(?)", word);
    }

}

テストコード。

    @Test
    public void transactionalNormallyNewNestedNew() {
        assertThat(myService.insertRequiredNewAndNestedNew("Hello!!")).isEqualTo(2);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!", "Hello!! Hello!!"));
    }

ロールバックする

外側のServiceクラス。

@Service
public class MyService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndNestedNewThrown(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredNewAndThrown(word + " " + word);
    }

}

内側のServiceクラス。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndThrown(String word) {
        jdbcTemplate.update("insert into sample(word) values(?)", word);

        throw new RuntimeException("Oops!!");
    }

}

テストコード。

    @Test
    public void transactionalNewNestedNewFailed() {
        assertThatThrownBy(() -> myService.insertRequiredNewAndNestedNewThrown("Hello!!"))
                .isInstanceOf(RuntimeException.class)
                .hasMessage("Oops!!");

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEmpty();
    }

内側のServiceクラスが例外をスローし、外側のServiceクラス内で捕捉する

外側のServiceクラス。

@Service
public class MyService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndNestedNewThrownAndCatch(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        try {
            nestedService.insertRequiredNewAndThrown(word + " " + word);
        } catch (RuntimeException e) {
            logger.error("insert failed", e);
        }

        return result;
    }

}

内側のServiceクラス。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndThrown(String word) {
        jdbcTemplate.update("insert into sample(word) values(?)", word);

        throw new RuntimeException("Oops!!");
    }

}

テストコード。

    @Test
    public void transactionalNewNestedNewFailedAndCatch() {
        assertThat(myService.insertRequiredNewAndNestedNewThrownAndCatch("Hello!!")).isEqualTo(1);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!"));  // 例外にならない
    }

内側のServiceクラスで例外は発生するものの、メソッドを例外で抜けない

外側のServiceクラス。

@Service
public class MyService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndNestedNewIgnoreFailed(String word) {
        int result = jdbcTemplate.update("insert into sample(word) values(?)", word);

        return result + nestedService.insertRequiredNewAndIgnoreFailed(word + " " + word);
    }

}

内側のServiceクラス。

@Service
public class NestedService {

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public int insertRequiredNewAndIgnoreFailed(String word) {
        try {
            // 構文誤りで実行に失敗するSQL
            jdbcTemplate.update("insert into sample(word) v(?)", word);
        } catch (RuntimeException e) {
            logger.error("sql error", e);
        }

        return 0;
    }

}

テストコード。

    @Test
    public void transactionalNewNestedNewIgnoreFailed() {
        assertThat(myService.insertRequiredNewAndNestedNewIgnoreFailed("Hello!!")).isEqualTo(1);

        assertThat(jdbcTemplate.queryForList("select word from sample order by word", String.class))
                .isEqualTo(List.of("Hello!!"));
    }

まとめ

Spring Frameworkを使った時の、REQUIREDな伝播レベルのトランザクションがネストした時に、例外をどう扱うかで
どのような挙動するのか、確認してみました。

ドキュメントに答えは書いてあるのですが、REQUIREDがネストしている時に中途半端な場所で例外を捕捉したりすると
厄介なことになりそうですね。

伝播レベルをわけるか、例外を捕まえるか、トランザクション境界を抜けてしまうか、このあたりをちゃんと考えて
書かないといけないですね。