第6回 Spring環境におけるトランザクション処理

今さら聞けないSpring framework

よく訓練されたアップル信者、都元です。2年越しの復活、Spring frameworkの話題です。ベルセ◯クかっつーの。正直2年も経ってると思っていませんでした。感覚的には半年くらい…そんなわけないか。…まぁ、なんつーか適当にやってますんで、適当にお付き合いください（汗

さて前回は「次回はトランザクションです」なんていう終わり方をしたので、約束は果たすぞ。2年経ってても次回は次回だ。

その前に、色々方針調整

で、2年も経ちますとSpring framework自体も進化しますし、外部から様々な影響を受けて私自身の考え方も変化します。

2年前は、Springの設定方法について XML-based、Annotation-based、Java-basedをご紹介し、まぁ適材適所で使っていきましょうね、というようなお話をしました。XML configは宣言的にbean定義が出来るのが個人的に好きで、Java config（Java-based）は記述がどうしても手続き的に見えてしまう事が引っかかっていました。要するにXML派寄りだったわけですが。

そして二年経った今、Java configの利用にも慣れ、「これはこれでよいものなだ」と認識を新たにした結果、XMLを完全に捨てたい派に鞍替えしています。

というわけで、前回ご紹介したコードは、全てJava configで書き直し、XMLレスなプロジェクトとして構成し直しました。というのがコレです。GitHubに上げておいたので、ご確認ください。

サンプルプロジェクト berserker Part6-0

このコードを、GitHubに上げておきました。ご興味のある方は、下記のように実行してみてください。

$ git clone https://github.com/classmethod-aws/berserker.git
$ cd berserker
$ git checkout refs/tags/part6-0
$ ./gradlew execute
:clean
:compileJava
:processResources
:classes
:execute
2015/07/13 15:53:37.882 [main] INFO  o.s.c.a.AnnotationConfigApplicationContext:510 - Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@402f32ff: startup date [Mon Jul 13 15:53:37 JST 2015]; root of context hierarchy
2015/07/13 15:53:38.919 [main] INFO  j.c.e.berserker.BerserkerApplication:50 - users = []
2015/07/13 15:53:38.921 [main] INFO  o.s.c.a.AnnotationConfigApplicationContext:862 - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@402f32ff: startup date [Mon Jul 13 15:53:37 JST 2015]; root of context hierarchy

BUILD SUCCESSFUL

Total time: 2.935 secs

トランザクション

さて今回はトランザクションの話。あまり深いことを論じ始めると分厚い本が書けてしまう分野でもありますので、まず概略をお話し、そしてその中の一部に絞って話を進めます。

まず「トランザクション」という言葉については、WikipediaのトランザクションやACIDの項目をさらっと読んでおいてください。要するに、よくある例えが銀行振込処理で、「振込元の残高を減らす処理」と「振込先の残高を増やす処理」をする時、その結果が「両方とも成功する」か「両方とも失敗する」か、どちらかになり、間違っても「どちらか一方だけが成功」した状態で処理が終わらないこと（原子性＝アトミック＝分割できない）を保証するような話です。

グローバルトランザクションとローカルトランザクション

上記の銀行振込の例では、イメージとしては1つのDBの中の世界で完結した話でした。しかしトランザクションというのは1つのDBの中でだけ起こるものではありません。例えば物理的に独立分離している2つのDBの間でトランザクション処理を行いたい場合もあります。

また、「DBへの書き込み」の話だけではなく、例えば「キューへのメッセージ送信」や「メールの送信」等、外部に対する影響を与えるような処理は（実際にどのように実現できるのかは置いといて）いずれもトランザクション処理の一要素になり得ます。

例えば、「DBからレコードを消す」ことと「キューへメッセージを送信する」ことをアトミックに処理したい、なんていうケースはそこそこ容易に想像がつくと思います。

このように、「DB」や「キュー」など、複数のリソースにまたがったトランザクション処理を「グローバルトランザクション」と呼ぶ一方、1つのリソース内で完結するようなトランザクション処理を「ローカルトランザクション」と呼びます。

グローバルトランザクションの話はかなりややこしいので、本稿ではこれ以上グローバルには触れません。話の中心はローカルトランザクションであり、しかもRDB上のローカルトランザクションに的を絞ります。

JDBCにおけるトランザクション管理

try {
  con = dataSource.getConnection();
  con.setAutoCommit(false);

  ps1 = con.prepareStatement("UPDATE xxx SET yyy=? WHERE zzz = 'foo'");
  ps2 = con.prepareStatement("UPDATE xxx SET yyy=? WHERE zzz = 'bar'");

  ps1.setFloat(1, 90);
  ps1.executeUpdate();

  ps2.setFloat(1, 110);
  ps2.executeUpdate();

  con.commit();
} catch (Exception e) {
  con.rollback();
  logger.error("rollbacked", e);
} finally {
  con.setAutoCommit(true);
}

こんなの見たことありませんか？ connectionに対して、commitやrollbackメソッドを呼ぶことにより、2つのUPDATE文をアトミックに束ねています。これはJDBCという仕様による、RDBのトランザクションを扱うためのAPIであって、他のトランザクションリソース（例えばキュー）に対するトランザクション処理には利用できません。

また、RDBを扱うAPIはJDBC以外にも様々（JDOやHibernate等）ありますが、それぞれやはりAPIは異なるため、JDBC以外におけるトランザクション処理には利用できません。

Springにおけるトランザクション管理 - PlatformTransactionManager

前述の通り、トランザクションは「DB」だけに対するものではなく、「キュー」等もトランザクション制御のためのAPI（メソッド等）を持っている場合があります。しかし、各種リソースがそれぞれ独自のAPIを定義しているため、一般的に統一的な操作方法がありませんでした。上記のコードは

SpringはこれらをPlatformTransactionManagerというインターフェイスに抽象化して統一し、同じ操作でトランザクションを制御できるようになりました。

PlatformTransactionManager txManager = new DataSourceTransactionManager(dataSource);

DefaultTransactionDefinition td = new DefaultTransactionDefinition();
td.setName("SomeTxName");
td.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
TransactionStatus status = txManager.getTransaction(td);
try {
  // ... アトミックに束ねたい処理たち ...
  txManager.commit(status);
} catch (Exception ex) {
  txManager.rollback(status);
  logger.error("rollbacked", e);
}

こんな感じです。RDB（DataSource）に対するトランザクション処理を担うPlatformTransactionManagerの実装クラスはDataSourceTransactionManagerです。今のところRDB以外のトランザクションリソースに触れる予定もなく、グローバルトランザクションにも触れないので、その他の実装クラスを利用することは当面ないと思ってください。

もう少し便利に - TransactionTemplate

上に挙げた例は、抽象化がなされているものの、JDBCのトランザクション制御と同じようなものでした。生JDBC記述に対してJdbcTemplateという便利クラスがあったのと同様に、生トランザクション記述に対してTransactionTemplateという便利クラスがあります。

TransactionTemplate template = new TransactionTemplate(txManager);
template.setName("SomeTxName");
template.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED);
template.execute(new TransactionCallback<String>() {

    @Override
    public String doInTransaction(TransactionStatus status) {
        // ... アトミックに束ねたい処理たち ...
        return "result";
    }
});

このように、コールバックメソッド内に書いた処理がすべてアトミックに処理されるようになります。executeメソッド呼び出し部分の記述は、Java 8のLambda記法を使えばもっとさらっと書けますね。

// ...
template.execute(status -> {
    // ... アトミックに束ねたい処理たち ...
    return "result";
});

宣言的トランザクション

さて、今まで見てきたトランザクション制御のコードは、非常に手続き的でした。「（ここからここまでをトランザクション処理とするために）コレを実行して、次にコレを実行して」というコードの記述方法です。

一方、宣言的なトランザクションとは「ここからここまでがトランザクション処理 である 」という記述です。具体的なアレしてコレして、という手続きを隠蔽したコードの記述方法であり、Springはこれをサポートしています。

@Transactional
public void execute() {
    // ... アトミックに束ねたい処理たち ...
}

ものすごいシンプルですね。@Transactionalアノテーションを付与したメソッドの入り口と出口までがトランザクション処理で、このメソッドが末尾まできちんと実行され、正常終了した場合はcommit、そうではなく例外によって終了した場合はrollbackします。このアノテーションの裏側の、隠蔽されて見えないところで、txManager.commit等が呼ばれるのです。

やってみよう

前回既に、@Transactionalアノテーションは利用しています。

public class BerserkerApplication {

  // ...

  @Transactional
  public void execute() {
    // 成功するDB書き込み操作
    userRepos.save(new User("torazuka", "$2a$10$abc"));
    // からの失敗
    throw new RuntimeException();
  }
}

例えばこのように、DBへの書き込み動作の後に例外でexecuteを抜けるようなコードを書いてみて、これを実行してみます。

この結果、新しいユーザがusersテーブルに追加されない（ロールバックされている）ことを確認してみましょう。

サンプルプロジェクト berserker Part6-1

このコードを、GitHubに上げておきました。ご興味のある方は、下記のように実行してみてください。

$ git clone https://github.com/classmethod-aws/berserker.git
$ cd berserker
$ git checkout refs/tags/part6-0
$ ./gradlew execute
:clean
:compileJava
:processResources
:classes
:execute
2015/07/13 16:00:05.098 [main] INFO  o.s.c.a.AnnotationConfigApplicationContext:510 - Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext@66d2e7d9: startup date [Mon Jul 13 16:00:05 JST 2015]; root of context hierarchy
2015/07/13 16:00:06.123 [main] INFO  o.s.c.a.AnnotationConfigApplicationContext:862 - Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@66d2e7d9: startup date [Mon Jul 13 16:00:05 JST 2015]; root of context hierarchy
Exception in thread "main" java.lang.RuntimeException
    at jp.classmethod.example.berserker.BerserkerApplication.execute(BerserkerApplication.java:47)
    at jp.classmethod.example.berserker.BerserkerApplication$$FastClassBySpringCGLIB$$a9cfb1d1.invoke(<generated>)
    at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
    at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:717)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
    at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
    at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281)
    at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
    at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
    at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:653)
    at jp.classmethod.example.berserker.BerserkerApplication$$EnhancerBySpringCGLIB$$4ff4c6e7.execute(<generated>)
    at jp.classmethod.example.berserker.BerserkerApplication.main(BerserkerApplication.java:29)
:execute FAILED

さて、DBの確認。

$ mysql -uroot -e "SELECT * FROM users" berserker
+----------+--------------------------------------------------------------+
| username | password                                                     |
+----------+--------------------------------------------------------------+
| miyamoto | $2a$10$vxq4n5VB4bsgUlBK9DXV9edhX911Qz/5iYqjLi/6qZPp8Xl7ZACKC |
| watanabe | $2a$10$MHPqWJ61alnBlUbvjEGK/uWRvwtYzolWCuFXW8YMJkT54HUB0H9iq |
+----------+--------------------------------------------------------------+

torazukaの行は増えていません。

まとめ

色々なトランザクション処理記述方法をご紹介しましたが、「宣言的トランザクション」が本命です。ただ、宣言的な記述は所謂黒魔術であり、慣れないうちは処理が追いかけづらい、というトレードオフがあります。

しかし、トランザクションの管理コードはプロジェクト内のあちこちに登場して、コードの見通しを悪くしてしまうため、この黒魔術を受け入れつつ、宣言的なトランザクションとしてプログラミングをするケースが多いと思います。

同じシリーズの記事

同じタグが設定された記事

絞り込むカテゴリーを選択