> 中村さん なるほどー。他のすべてのTM対応RMがprepareに応じ終わったタイミング（というか順序）で、すなわち、すべてのTM対応RMがcommit/abortの両方が実行可能なタイミングで、TM未対応なRMに対する処理を開始できるのがポイントなんですねー。

なんか、予定あわせのときに、あとでキャンセルね！といっても怒らなそうな人から予定の確認をとっていくのに似てますね（笑）。

ご丁寧なアドバイス、ありがとうございました。

SeasarのJTA実装における非XAなDataSourceの扱いと同じことなのに、何で気づかなかったんだろう・・・と自己嫌悪。(http://www.csus4.net/d/2005/05/15/j2eestudy/#more-156)

> koichikさん > 結局ややこしい状況を作ってませんか たしかに、データをオンメモリ上に期間長めにもつと、データベース上のデータとズレがでやすくなるため、そのような悩みは発生しますね。 ユーザーから見た一貫性を重視するか（反面、楽観的同時実行制御でNGとなる危険性も！）、適宜データベースからのデータを読み込んで、データベースの最新データをユーザーに見せること（表現イマイチ）を重視するかについて、「もうちょっと具体的な事例」にもとづいて、どちらがよいか判断する必要がありそうですね。

> いちいちdetachしてattachするのが面倒に思えるので。

1 HTTP Session = 1 Unit of Work なら面倒じゃないとも思えないけれど． 実際に更新するオブジェクトはバージョニングでチェックされるけど，更新しないオブジェクトはチェックされないじゃないですか．でもでも，更新内容がそういうのに依存する場合はそれらが最新じゃないとまずかったりして，そうすると Hibernate なら lock(Object) とかで再読込しなきゃいけないケースが多々あったりして，結局ややこしい状況を作ってませんかという気のせいが． 要するに，あるトランザクションがそれ以前のトランザクションに依存することになりやすくて，それをちゃんとコントロールする方がよっぽど面倒でリスクが高いと感じてしまうのです． なので，自分的には 1 Request = 1 Session の方がシンプルな感じがしますね．

RMの実行順序の件ですが、 例えば、TM対応のRMが２つ(RMa､ RMb)、TM未対応のRMが１つ(RMc)あって、この３つをトランザクションに入れたい場合、実行順番として、RMcを最後に実行すれば、なんとかなるって話ですね。 RMcが失敗した際に RMa、RMbはロールバックができるので。 これをRMｃ→RMb→RMaという順番でやると、 RMcが成功してRMbも成功してRMaが失敗なんかしたりすると、RMcはロールバックできないのでトランザクションにならなくなる。 またTM未対応のRMが２つ以上あるとお手上げだよね、という話をしてました。

1 Request = 1 Sessionの話ですが、

http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#transactions-basics-uow

に記述されています。ただ、「The most common pattern」なので、必ずしも1 Request = 1 Sessionである必要はないのだと思います。また、次回にでも獄長さんに聞いてみます。