質問: via によると 「PHPセッションはデフォルトでファイルに保存され、それらのファイルはflock()システムコールを使用してPHPプロセスによってロックされ、スクリプトが完了するかsession_write_close()によってセッションが手動で閉じられるまでロックされたままです。つまり、ロックを保持しているプロセスによってセッションファイルがロック解除されるまで、他の要求はsession_start()でハングします。」 だそうです。 よって、セッション機能を実現する他の方法としていろいろと候補がありますが、エンタープライズシステムとして利用するには何をもって実現するのがよいのでしょうか? 別にワードプレスに限ったことではない普通のPHPアプリケーション、Webフレームワークを使ったアプリケーションにも通用するデフォルトのセッションを使わない方法を探しています。 私が探した候補としては各種DBをセッション保存領域とすることです。
回答: こういう時は本家のマニュアルを参照したほうが良いと思います。 > > 注意: > > ファイルベースのセッション (PHP のデフォルト) は、 session_start() でオープンしたり session.auto_start で暗黙のうちに開始したりしたセッションのセッションファイルをロックします。 いったんロックがかかったら、そのスクリプトが終了するなり session_write_close() を呼んでセッションを閉じるなりしない限り、 他のスクリプトからはそのセッションファイルにアクセスできません。 > > > これは、たとえば AJAX を使いまくっていて同時に複数のリクエストが発生したりするウェブサイトで問題になります。 この問題への対処方法として一番お手軽なのは、セッションに対して必要な変更が終わったらすぐに session_write_close() を呼ぶことです。スクリプトの最初のほうで呼ぶほうが好ましいでしょう。 あるいは、ファイルではなく別のバックエンド (同時アクセスに対応しているもの) を使うという手もあります。 > > より引用 > > > すなわち、ファイルのロックが発生するのは、同じセッションIDについて同時にアクセスした場合です。そのようなケースは古典的なウェブアプリケーションではあまりないのですが、上記にあるように、AJAXにより複数のAPIが同一セッションでアクセスを同時に行う場合にはありえます。そのような場合には、セッションを使い終わったら直ちにsession_write_close()するか、場合によってはsession_abort()してもよいと思います。そうすれば、ロック待ちの問題はあまり顕在化しないと思います。 独自のセッション管理システムを作成することは、脆弱性がとても入りやすいので、まったくお勧めしません。私が見た範囲でも、以下の脆弱性が存在したケースがあります。 * ディレクトリトラバーサル * SQLインジェクション * 安全でないデシリアライゼーション ディレクトリトラバーサルの例は、この記事や、この記事をご覧ください。 安全でないデシリアライゼーションは、かつてJoomla!に存在した問題で、PHPの脆弱性との合わ技ではありますが、重大な脆弱性となりました。詳しくはこの記事を御覧ください。 ということで、フレームワークの標準のセッション管理システムをお使いになることをお勧めします。