質問 > その他 > セッション排他制御でのバグについて |
その他
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
投稿者 | スレッド |
---|---|
izumin |
投稿日時: 2011/6/21 14:57
対応状況: 確認中
|
半人前 登録日: 2011/6/21 居住地: 東京 投稿: 16 |
セッション排他制御でのバグについて izuminと申します。
セッション変数の排他制御でバグがあるとのチケットを見つけました。 http://svn.ec-cube.net/open_trac/ticket/571 本件は、まだ対応されていないようですが文中にある 『現状確認されているのは、「セッションを OPEN しているのにも関わらず, 別のファイルからアクセスすると READ してしまう現象」となります。 』 これからどのような現象か読み取れませんでした。 セッションオープン中は、ロックをかけているのでREAD出来てはいけないがREAD出来てしまう、という事でしょうか。 また、その結果どういった問題が発生するのでしょうか。 ※デッドロック等が発生するのでしょうか。 どなたか、ご回答頂けると非常に助かります。 宜しくお願いいたします。 |
134 |
投稿日時: 2011/6/21 15:32
対応状況: −−−
|
一人前 登録日: 2009/10/20 居住地: 京都市 投稿: 91 |
Re: セッション排他制御でのバグについて 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 |
投稿日時: 2011/6/21 16:04
対応状況: −−−
|
半人前 登録日: 2011/6/21 居住地: 東京 投稿: 16 |
Re: セッション排他制御でのバグについて >134様
非常に丁寧なご返信ありがとうございます!非常に助かりました。 排他制御が効いていない為、書き込みと読み込みの順番が守られず 更新前の古いセッションデータを参照してしまう事がある、その結果、処理に不整合が起きる(例はちょっと思いつきませんが古いカート情報を見てしまう等)と言った理解で宜しいでしょうか。 また本件の回避策はあるのでしょうか。 以下のサイトでセッション管理をMongoDBへ変更しているようですが134様がおっしゃるようにsession_set_save_handlerを使用すると発生する事象なのであれば、以下対応では解消しないように思えます。 http://d.hatena.ne.jp/red_snow/20100817/1282019707?utm_source=twitterfeed&utm_medium=twitter お忙しいところ、恐れ入りますがよろしくお願い致します。 |
134 |
投稿日時: 2011/6/21 17:20
対応状況: −−−
|
一人前 登録日: 2009/10/20 居住地: 京都市 投稿: 91 |
Re: セッション排他制御でのバグについて > 排他制御が効いていない為、書き込みと読み込みの順番が守られず
> 更新前の古いセッションデータを参照してしまう事がある、その結果、処理に不整合が起きる(例はちょっと思いつきませんが古いカート情報を見てしまう等)と言った理解で宜しいでしょうか。 はい、実際に検証はしていませんが、そういうことだと思います。 > 以下のサイトでセッション管理を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レベルでのロックはややこしそうなので除外しました。 私もぜひ他の皆様のご意見を伺いたいです。 |
izumin |
投稿日時: 2011/6/21 18:51
対応状況: −−−
|
半人前 登録日: 2011/6/21 居住地: 東京 投稿: 16 |
Re: セッション排他制御でのバグについて ご回答ありがとうございます!
なるほど、5.3〜では解消されている可能性もあるのですね。 まずは5.3以前で再現してみて同様の条件で5.3以降で再現するか検証してみます。 再現が難しそうですが。 案1は134様がおっしゃる通り弊害が気になりますね。 今の構成は、様々な弊害があった経緯の上での構成である可能性もありますし。 案2はきちんとテストしてやっていると工数がそれなりに膨らみそうですね。 普通に運用されているようなので、本件で大きな障害は発生していないんでしょうか・・・ ありがとうございます。 |
izumin |
投稿日時: 2011/6/24 10:11
対応状況: −−−
|
半人前 登録日: 2011/6/21 居住地: 東京 投稿: 16 |
Re: セッション排他制御でのバグについて 本件どのページで再現しますでしょうか。
再現させる方法などご存じの方がいらっしゃいましたらご教授頂けると助かります。 |
seasoft |
投稿日時: 2011/6/24 11:13
対応状況: −−−
|
神 登録日: 2008/6/4 居住地: 投稿: 7367 |
Re: セッション排他制御でのバグについて 基本的には全てのページです。特に、resize.php による縮小画像を表示しているページでは発現しやすかったと記憶ています。
|
134 |
投稿日時: 2011/6/24 13:03
対応状況: −−−
|
一人前 登録日: 2009/10/20 居住地: 京都市 投稿: 91 |
Re: セッション排他制御でのバグについて 下記の手順で再現できました。
環境は下記の通りです。 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 をコメントアウトしたところ 排他処理が効いて、正常にログイン情報が残りました。 ただ、セッションがクローズされるまで次のリクエストが待たされるので レスポンスが遅くなりました。(当たり前ですね^^;) |
izumin |
投稿日時: 2011/6/30 20:17
対応状況: −−−
|
半人前 登録日: 2011/6/21 居住地: 東京 投稿: 16 |
Re: セッション排他制御でのバグについて >seasoft様
ご回答ありがとうございます。 全てのページなのですね。 参考に致します。 |
izumin |
投稿日時: 2011/6/30 20:32
対応状況: −−−
|
半人前 登録日: 2011/6/21 居住地: 東京 投稿: 16 |
Re: セッション排他制御でのバグについて 134様
再現手順ありがとうございます! 基本的に1クライアントが複数PHPファイルに対して同時にアクセスにいき更にレスポンスが悪い時に発現するのですね。 ケースとしては、かなりのレアケースでしょうか。 こちらは、PHP5.3.5なので同様の手順で再現するか確認してみます。 ありがとうございました。 |
(1) 2 » |
スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |