【Google App Engine】 分散トランザクションを非同期に実行する

トランザクションは意識しないのが一番

　歴史は繰り返すんだろうか。トランザクションに関しては、こんな感じで話がループしている気がしている。

　
１）　トランザクション宣言を明示的にコードに記述（ホスト、ODBC/JDBC)　
２）　生産性が低くなり新しいフレームワークが出現（EJB、Seasar2)
３）　新しいイノベーション誕生(cloud)、トランザクションを明示的に宣言、以下繰り返し

　トランザクションについては、2年前にも一度述べたことがある。実装が難しく不具合になりやすいので、生産性、品質を上げるには、開発者にトランザクションを意識させないことが一番である、といった感じのことを書いたつもりであった。

【EC開発体験記-トランザクション処理-】古くて新しい永遠のテーマ

　GAEにおいても方法論は異なるとは思うが、開発者にトランザクション処理を意識させたくないという私のスタンスは今でも変わっていない。GAEにもそのうち新しいフレームワークが現れて生産性が高くなっていくかもしれない。
　でもエンジニアの性というか、トランザクションを議論するのは、いつの時代でも好まれるようである。何百時間とかけて、そのくせ不完全だったりする（私も例外ではない）。
　モデリングの話もそうだったが、エンジニアは基本的に穀潰しである。
　とはいえ、過去の考え方をあらためて学ぶことは、それはそれで有益に思えることもある。　ということで、一応、復習することにする。

トランザクションコンテキストは野球のボール

　EJBが登場したとき、メソッドの呼び出しだけで、何でトランザクション処理が可能になるのかわからなかった。実はコンテナがメソッドを管理していて、呼び出し時にトランザクションコンテキストの受け渡しを行うことで実現していたのだが、これを理解できたときはとても感動したものだった。（しかし、重いEJBはパフォーマンスが悪かったので普及せず、Seasar2がそれを改善した。AOPによりトランザクションを実現しているのを知ったときは一本取られたと思った。）

　で、その具体的な仕組みを説明する。

　トランザクションコンテキストは何かというと、マジックで番号が記入された野球のボールのようなものと考えればよい。担当者に仕事を依頼する際に、受付番号を書いたボールも一緒に渡すことにして、もし担当者が処理に失敗した場合は、ボールに×を書いて返すようにする。担当者は別の担当者に再委託もできるが、その際にも必ずボールも渡すこととする。最後に依頼者にボールが戻ってきたときに、×が付いているかをチェックして、処理の成功失敗を判断する。成功であればその受付番号の処理を最終的にコミットとする。失敗であれば何もしないでボールを捨てる。受付番号が記入されているので同時並行処理が可能なのである。

受注と在庫引当を分散トランザクション実行

　以下は、分散トランザクション実行のアイデアである。（このBlogでは、受注とか在庫とかのEC単語が唐突に出てくる。）上記のトランザクションコンテキストを受け渡す方法を元に考えたものだ。図には書いていないが、TaskQueueによる在庫引当では冪等性（べきとうせい）も考慮する。
　受注受付のタイミングと在庫更新のタイミングは異なるが、2重引当などの致命的な問題は起こらないはずである。ただ、実際より在庫が少ないとみなされる瞬間がある。
　ブラウザーでステータスを確認するか、ステータス更新時にメールするなど、基本的にはステータス参照で対応するところが非同期の特徴である。
　なお、口座送金処理といったものへの応用は、もしかしたら可能かもしれないが、参照のタイミングが一致しないので、この方法ではたぶん無理だと思う。