> 排他制御が効いていない為、書き込みと読み込みの順番が守られず
> 更新前の古いセッションデータを参照してしまう事がある、その結果、処理に不整合が起きる（例はちょっと思いつきませんが古いカート情報を見てしまう等）と言った理解で宜しいでしょうか。

はい、実際に検証はしていませんが、そういうことだと思います。

> 以下のサイトでセッション管理をMongoDBへ変更しているようです が134様がおっしゃるようにsession_set_save_handlerを使用すると発生する事象なのであれば、以下対応では解消しないように思えます。

sessionのオープンもクローズも、DBのトランザクション内で行われると
デッドロックの可能性があるかと思いますが、そうでなく
デッドロックが起こるケースというのは、私の知識では原因が思い当たりません…。

デッドロックの原因が、読み書きの順番が保証されないことにあるのか
分かりませんが、izuminさん が仰るとおり、MongoDBを導入することで
順番が保障されるようになる、とは思えませんね…。
少なくともデッドロックを起こす可能性は無くせるか、減らせると思いますが。

> また本件の回避策はあるのでしょうか。

AMUAMU様より、PHP5.3でバグがFIXされているという情報もありますが
検証が必要ですね…。
http://xoops.ec-cube.net/modules/newbb/viewtopic.php?topic_id=5090&forum=1

その他の方法としては

案1.session_set_save_handler を使用しない
→セッションデータはファイルに書き出されるようになり、
　排他制御も効くと思うのですが、どのような弊害があるか分かりません…。

案2.独自にロックの仕組みを作成する
→例えば、SC_Helper_Session::sfSessRead() 時に
　セッションIDをファイル名としたダミーのファイルを
　flock するなどして、独自に排他の仕組みを作る

などでしょうか。
DBレベルでのロックはややこしそうなので除外しました。

私もぜひ他の皆様のご意見を伺いたいです。

>134様

非常に丁寧なご返信ありがとうございます！非常に助かりました。

排他制御が効いていない為、書き込みと読み込みの順番が守られず
更新前の古いセッションデータを参照してしまう事がある、その結果、処理に不整合が起きる（例はちょっと思いつきませんが古いカート情報を見てしまう等）と言った理解で宜しいでしょうか。

また本件の回避策はあるのでしょうか。

以下のサイトでセッション管理をMongoDBへ変更しているようですが134様がおっしゃるようにsession_set_save_handlerを使用すると発生する事象なのであれば、以下対応では解消しないように思えます。

http://d.hatena.ne.jp/red_snow/20100817/1282019707?utm_source=twitterfeed&utm_medium=twitter

お忙しいところ、恐れ入りますがよろしくお願い致します。

PHPのデフォルトのセッション機構を使用すると、セッションデータは
ファイルとして書き出され、サーバ上に保存されます。
また、セッションのOPEN中は別のファイルからセッションをOPEN出来ないよう、
排他処理がかかっています。

session_set_save_handler を使用すると、独自のセッションハンドラを設定し、
ファイルではなく、セッションデータをDBに保存するようなことができます。
実際にEC-CUBEは session_set_save_handler を使用して
DBにセッションデータを保存しているのですが、session_set_save_handler を
使用すると、排他制御が効かない、ということのようです。

具体的には、下記の例ですと、



(3)も(4)も、(2)で書き込まれた内容を元に処理を行い、
(5)→(6) と書き込みを行うため、
(5)で書き込んだ内容が、(6)で上書きされてしまう、ということです。

たとえば、index.php も resize_image.php も、
変数を1ずつインクリメントするだけの処理をしている場合、

(1)で0を読み込む
(2)で1を書き込む
(3)で1を読み込む
(4)で1を読み込む
(5)で2を書き込む
(6)で2を書き込む
(7)で2を読み込む
(8)で3を書き込む

となって、最終的に 3 がセッションに保存されます。

対して、デフォルトのセッション機構だと、排他制御のおかげで
読み込み→書き込みが必ず順に行われ

0を読み込む
1を書き込む
1を読み込む
2を書き込む
2を読み込む
3を書き込む
3を読み込む
4を書き込む

となって、最終的に 4 がセッションに保存されます。

デッドロックはDB側で変なロックをしていない限り大丈夫です。

ややこしいですが、ご理解の助けになったでしょうか…

izuminと申します。

セッション変数の排他制御でバグがあるとのチケットを見つけました。
http://svn.ec-cube.net/open_trac/ticket/571

本件は、まだ対応されていないようですが文中にある

『現状確認されているのは、「セッションを OPEN しているのにも関わらず, 別のファイルからアクセスすると READ してしまう現象」となります。 』

これからどのような現象か読み取れませんでした。
セッションオープン中は、ロックをかけているのでREAD出来てはいけないがREAD出来てしまう、という事でしょうか。
また、その結果どういった問題が発生するのでしょうか。
※デッドロック等が発生するのでしょうか。

どなたか、ご回答頂けると非常に助かります。
宜しくお願いいたします。