そろそろポジションペーパ書きに飽きて来たので手抜きをしてしまいました。
いかんですね。
### Unit Of Work : まさゆきさん
* Hibernate との比較で語られていたので、わかりやすかったように思う。
* ちなみに、EOF/WebObjects関連の資料は、WebObjects基礎研究室 とか、WebObjects関連プレゼン資料 にあります。
#### ちょいとHibernateに対する疑問
* 1 Request = 1 Sessionなる考え方にどうもなじめないなぁと。EOF/WebObjectsの1 HTTP Session = 1 Unit of Workの方がシンプルな気がするのです。なぜなら、複数画面に渡る編集機能を実現することを考えた場合を考えると、いちいちdetachしてattachするのが面倒に思えるので。（と某mixi日記に書いたのですが、獄長から「Hibernateでも1 HTTP Session = 1 Unit of Workでつかえるよん」とツッコミが。1 Request = 1 Sessionと1 HTTP Session = 1 Unit of Workを使い分けるというのがよい？）
* なんであんなにListenerが必要なのだろうか？実行の順序性に意味がありそうな一連のオペレーションを、Event, Listenerモデルで構築する意味がわからない・・・
### Identify Map
* Fawlerの語りの意味を読み解く作業は不毛感ありまくりな気がするなぁ。
* FawlerはIdentify Mapをキャッシュと密接な関連を持つものと位置づけているようだ。
### Lazy Load
* t-wada さん、相変わらずすばらしい発表ですね・・・。構成がイイ！なんというか、つかみがうまいんですよねー
* 具体的な事例、コードを見る視点と、抽象的なレベルでのアーキテクチャの捉え方の視点をいったりきたりする感じがとてもイイ！です。
### WRサーガ：非TM対応RM, キュー形トランザクション
* ちょっと仕込みが足りなかった感じ。反省
* べき等のあたりの説明って、理解できました？ ＞ 皆様
* あれ？ 困ったときのkoichikさん頼り ができないじゃん！・・・と思ったらafukuiさんがいらしていたので・・・よかった！助かった！
* 【お願い】TM未対応RMの実行順序を工夫するあたりで、中村さん（？）が言っていた内容がよく聞こえなかったのですが、誰か教えてもらえません？
* 次回で無事終わることができる・・・かもしれない。
EOF/WebObjectsの資料、あとで必ず読みます。ありがとうございます。
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である必要はないのだと思います。また、次回にでも獄長さんに聞いてみます。
声小さくてほんとすいません(汗
RMの実行順序の件ですが、
例えば、TM対応のRMが２つ(RMa､ RMb)、TM未対応のRMが１つ(RMc)あって、この３つをトランザクションに入れたい場合、実行順番として、RMcを最後に実行すれば、なんとかなるって話ですね。
RMcが失敗した際に RMa、RMbはロールバックができるので。
これをRMｃ→RMb→RMaという順番でやると、
RMcが成功してRMbも成功してRMaが失敗なんかしたりすると、RMcはロールバックできないのでトランザクションにならなくなる。
またTM未対応のRMが２つ以上あるとお手上げだよね、という話をしてました。
こっちでも獄長獄長言われとる．．．
> いちいちdetachしてattachするのが面倒に思えるので。
1 HTTP Session = 1 Unit of Work なら面倒じゃないとも思えないけれど．
実際に更新するオブジェクトはバージョニングでチェックされるけど，更新しないオブジェクトはチェックされないじゃないですか．でもでも，更新内容がそういうのに依存する場合はそれらが最新じゃないとまずかったりして，そうすると Hibernate なら lock(Object) とかで再読込しなきゃいけないケースが多々あったりして，結局ややこしい状況を作ってませんかという気のせいが．
要するに，あるトランザクションがそれ以前のトランザクションに依存することになりやすくて，それをちゃんとコントロールする方がよっぽど面倒でリスクが高いと感じてしまうのです．
なので，自分的には 1 Request = 1 Session の方がシンプルな感じがしますね．
> まさゆきさん
Hibernateはまったく使ったことはないのですが、さらりと読んでみました。
12.1.4. Common issuesによると、Hibernate Sessionはスレッドセーフでないので、HTTP Sessionに入れちゃアカン！っていってますね。Webobjectsの場合、フレームワーク側がデフォルトのO-R MapperのSessionに対するスレッド同期をとってくれるので、このような心配はないのですけど。 session-per-application-transactionの実現方法が気になるので、Hibernateのマニュアルをもうすこし読んでみます。
> 中村さん
なるほどー。他のすべての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となる危険性も！）、適宜データベースからのデータを読み込んで、データベースの最新データをユーザーに見せること（表現イマイチ）を重視するかについて、「もうちょっと具体的な事例」にもとづいて、どちらがよいか判断する必要がありそうですね。