izuminと申します。

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

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

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

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

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

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側で変なロックをしていない限り大丈夫です。

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

>134様

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

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

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

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

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

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

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

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

> 以下のサイトでセッション管理を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レベルでのロックはややこしそうなので除外しました。

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

ご回答ありがとうございます！

なるほど、5.3〜では解消されている可能性もあるのですね。
まずは5.3以前で再現してみて同様の条件で5.3以降で再現するか検証してみます。
再現が難しそうですが。

案１は134様がおっしゃる通り弊害が気になりますね。
今の構成は、様々な弊害があった経緯の上での構成である可能性もありますし。

案２はきちんとテストしてやっていると工数がそれなりに膨らみそうですね。

普通に運用されているようなので、本件で大きな障害は発生していないんでしょうか・・・

ありがとうございます。

本件どのページで再現しますでしょうか。
再現させる方法などご存じの方がいらっしゃいましたらご教授頂けると助かります。

基本的には全てのページです。特に、resize.php による縮小画像を表示しているページでは発現しやすかったと記憶ています。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

下記の手順で再現できました。

環境は下記の通りです。
EC-CUBE 2.11.1
apache 2.2 (KeepAlive=ON timeout=5 max=100)
PHP 5.3.3
PostgreSQL 8.3.12

1.
トップページにお勧め商品ブロックを配置する。
（デフォルトのお勧め商品ブロックは resize_image.php を使用しています）

2.
data/class/LC_Page_ResizeImage.php の process() メソッド内で
sleep(15);
とし、レスポンスの悪い状況を再現。

3.
トップページを未ログイン状態で表示し、15秒以内にログインブロックからログインする。

4.
ログインボックスに「ようこそ○○様」と表示され、ログインできているように見えるが
別のページへ遷移すると、未ログイン状態になっている。

次に、SC_Helper_Session の session_set_save_handler をコメントアウトしたところ
排他処理が効いて、正常にログイン情報が残りました。
ただ、セッションがクローズされるまで次のリクエストが待たされるので
レスポンスが遅くなりました。（当たり前ですね^^;）

>seasoft様

ご回答ありがとうございます。
全てのページなのですね。
参考に致します。

134様

再現手順ありがとうございます！
基本的に1クライアントが複数PHPファイルに対して同時にアクセスにいき更にレスポンスが悪い時に発現するのですね。
ケースとしては、かなりのレアケースでしょうか。

こちらは、PHP5.3.5なので同様の手順で再現するか確認してみます。
ありがとうございました。