>>180
残念ながら、その、タンデムじゃない(;´д｀)
>>179
そうか、良かったな。おれっちも安心して寝ることができる。もっとがんばれ。
>>181
EOEditingContextで生成されたオブジェクトはショッピングカートを連想すればいい。
insertするためのトランザクション、Updateするための…Deleteするための…
といった更新系のトランザクションをするためのオブジェクト群が「とても効率よく」
管理されたショッピングカートのようなもので、あるメソッド（saveChangesメソッド）を
実行すれば、カートに入っているトランザクションを一つずつ処理していく。
排他制御については詳しく書くのが面倒なんでカットするけど、上位層では
EOF内での排他処理、下位層ではよりDBに密着した処理をやっている。
が、PGはそこんとこはほとんど意識しなくても構わない。最近テクノロジックのMLに
ロックに関する話題がpostされてるがそれなりに勉強になるのでオススメ。

Sessionクラスはオブジェクトが生成されたとき（ユーザーからのアクセスが発生したとき）
EOEditingContextを生成して保持しておき、defaultEditingContextで参照できるように
なるんだが、そのオブジェクトはSessionが生きている間は有効で（ったりめーか（笑））、
DBに対してフェッチした時、EOFの下位層がレコードセットの各Row、そして各カラムを
EOというオブジェクトに変換する。その後、SessionのEOEditingContext（defaultEditingContext）に
マッピングするわけだ（なんで、DBからフェッチして生成されたEOには、EOglobalIDという
オブジェクトが完全にユニークな形で負荷される）。
EOEditingContextはマッピングされたEOを常に関ししておいて、EOが追加されたり
削除されたり更新されたりすると、それぞれDBに対してやるべき処理にレジストする。

と、いうイメージでいいんじゃない？