Q&A
Closed
SpringBootの@Transactionalについてご教示ください。
@Transactional(rollbackFor = Throwable.class)
public void shori() {
try {
// テーブルAを登録する処理
} catch (Exception e) {
// テーブルBにエラーを登録する処理
// 例外は再スローしない
}
}
とTransactionalをメソッドに指定した場合
例外をキャッチしていても、再スローしなくても
ロールバックされるのでしょうか？
例外が発生した際に、処理は動いていますが
テーブルBにデータが登録されてない状況で、
トランザクションに関して調査しております。
※追記
DBは、PostgreSQLとなります。
別トランザクションにしていないならば、テーブルBもロールバックされているのでは？
@shibaken_f26
Questioner
ご回答ありがとうございます。
Transactionalをつけたメソッドが例外で抜けたときに
ロールバックされるのかと思っているのですが、
try内で例外が発生した時点でロールバックされることが決まって
テーブルBの処理もロールバックされるということになるのでしょうか？
@Transactional(rollbackFor = Throwable.class)を宣言したメソッドが例外をスローするのが順当だと思うのですが、上のshoriメソッドは、例外をスローする宣言になっていないのと、テーブルBにデータが登録されてない状況ということで、先ほどの回答をしました。
shoriメソッドが例外をスローする可能性があるなら、
public void shori() throws Exception { }のような宣言になると思います。
↑こう変えると、もしかして動き方も変わるかも知れませんが、すみませんが不確実です。
@shibaken_f26
Questioner
ありがとうございます。
SpringBoot は全く分からないので、データベース側だけで考えていますが・・・
「テーブルAを登録する処理」と「テーブルBにエラーを登録する処理」は同じトランザクションに束ねられているが、エラーのためコミットされなかったので、接続が切断された際にロールバックされたという話ではないのでしょうか？
データベースは何ですか？
接続が切断された際にコミットされるのか (暗黙コミット)、ロールバックされるのかは製品によって異なるそうです。
また、DB によってはトランザクションの対象にならない SQL 文(CREATE TABLE など) があるそうです。
@Transactional(rollbackFor = Throwable.class)
public void shori() {
try {
// テーブルAを登録する処理
} catch (Exception e) {
// テーブルBにエラーを登録する処理
// 例外は再スローしない
}
}
次のコードに相当する：
begin;
try {
try {
// テーブルAを登録する処理
} catch (Exception e) {
// テーブルBにエラーを登録する処理
// 例外は再スローしない
}
} catch (Exception e) {
rollback;
}
commit;
だからAは常にコミットする。
Bは（Aがミスをしたときに）コミットを実行することがある；
ロールバックはない