DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions

gotanda.rb#52@オンライン "DB外の副作用をトランザクションから分離しよう"

[rryu]

副作用というかロールバックできない処理をDBのトランザクションに入れてもロールバック時に無かったことにはできないので意味はないという感じ。

[atico]

私のシステムでは、SQSに直接書き込むのではなく、SQSに書き込むというJOB用のレコードをRDBに書き込む。after commitのイベントでそのレコードを読み込んでSQSに実際に送信することでロールバックも出来る対応。

[kagehiens]

まぁ、分離というかロールバックできない処理はロールバックできる処理がすべて成功で完了してから始める、以外のやり方は無意味でしょ。（失敗時にも別な後処理はあるかもだけど）

[cpw]

DBにメールを送るレコードを書き込むのがいいよ。同一トランザクションで扱えるようになる。んで、実際の処理を別ジョブで実施。責任範囲が分離されるからプログラムが劇的に書きやすくなるよ。

[murasuke]

Railsがよくわからないけど、トランザクションモニターみたいなものをやりたい？https://ja.wikipedia.org/wiki/%E3%83%88%E3%83%A9%E3%83%B3%E3%82%B6%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%B3%E3%83%A2%E3%83%8B%E3%82%BF%E3%83%BC

[onesplat]

分離って何？

[bopperjp]

わー、、全然考えてこなかったから、死ぬほどためになるわー。

[ohbarye]

当たり前だけどあまり語られてないことについて。結論、RailsならIsolatorとAfterCommitEverywhereおすすめ。内部実装も読みやすいしRailsのinstrumentationやcallbackをうまく使っていて面白い