Sessions: FilesystemStoreの競合状態

ロックする代わりに、トランザクションベースのシステムはどうですか？ SessionオブジェクトはlastModifiedフィールドを運ぶことができます。 セッションをセッションストアに保存し直そうとすると、最後に読み取られてから変更されたことを示すエラーが返されます。 その後、プログラマーはセッションを再度取得して再試行することを選択できます。

それはうまくいく可能性があり、クリーンアップする必要のあるロックがなく、デッドロックの可能性がないという利点があります。 リクエストの実行内容によっては、開発者が意味のある再試行を常に実行できるかどうかはわかりません。 ロックは間違いなくより安全なオプションだと思いますが、APIが失敗の可能性を明確に文書化し、開発者がそれらのエラーを熱心に処理すれば、トランザクションは確かに機能する可能性があります。

とはいえ、 FilesystemStoreがトランザクションを使用する場合でも、APIは、ロックを使用するストレージバックエンド用に準備する必要があると思いますが、それは、 session.Save()複数回呼び出すことを禁止するか、新しいsession.Release()導入することを意味します。

RediStoreに影響するため、この問題に続いて。 情報をありがとう@cless

長期的には正しいことをする以外に、現時点では特に好みはありません:)もちろん、既存のAPIも維持したいと思います。 また、あちこちにロックを追加すると、複雑さとオーバーヘッドが大幅に増加しますが、これも避けるとよいでしょう。

この問題を解決する他のセッションフレームワークの例はありますか？ 彼らが何をしているのか知りたいです。

デフォルトのphpセッションハンドラーがファイルシステムベースのロックを使用していることを知っています（php 5.4 tarballでは、これがファイルext/session/mod_files.cあることを確認しました。 ext/standard/flock_compat.cによって提供されるflockを使用します）。

phpが評判を考えれば良い例かどうかはわかりませんが、現時点で私が知っているのはphpだけだと思います。 他のフレームワークを見つけて、それらがどのように問題を解決するかを確認するために、周りを見回してみます。

Flask、Pyramid、またはDjangoがこれらをどのように処理するかを知りたいと思います。 時間があれば見ていきます。 誰かがそのコードベースに精通していれば、Railsも興味深いでしょう。

PyramidとFlaskはどちらもデータの保存にCookieを使用しているようですが、どちらも競合状態を処理していないと思われます。 私はドキュメントを簡単に読んだだけなので、間違っている可能性があります。

Djangoはサーバー側のセッションデータをサポートしているので、そのコードを少し見ていきます。

デフォルトのDjangoセッションバックエンドはデータベースであり、これは私がよく知らないDjangoデータベース抽象化レイヤーを使用しているため、解釈するのが困難です。 しかし、私はこのコメントをファイルシステムバックエンドで見つけました：

        # Write the session file without interfering with other threads
        # or processes.  By writing to an atomically generated temporary
        # file and then using the atomic os.rename() to make the complete
        # file visible, we avoid having to lock the session file, while
        # still maintaining its integrity.
        #
        # Note: Locking the session file was explored, but rejected in part
        # because in order to be atomic and cross-platform, it required a
        # long-lived lock file for each session, doubling the number of
        # files in the session storage directory at any given time.  This
        # rename solution is cleaner and avoids any additional overhead
        # when reading the session data, which is the more common case
        # unless SESSION_SAVE_EVERY_REQUEST = True.
        #
        # See ticket #8616.

これは、セッションファイルの内容が破損しないようにすることを示唆しているようですが、競合状態が発生しないことを示唆しているわけではありません。 誰かがDjangoの経験を持っているなら、cless / sessions @ f84abedのようなテストケースを見るといいでしょう。
Stackoverflowは、Djangoがセッションで競合状態になっている可能性があることも示しているようです： http ：//stackoverflow.com/search？q = django + session + race + condition

了解しました。FileSystemStoreには、セッションストアの破損を防ぐために、すでに粗粒度のミューテックスがあります。 一部のリクエストの一貫性を高めるためだけに、リクエストごとに多くのオーバーヘッドが追加されるため、ライブラリに追加の保護をどの程度追加する価値があるかはわかりません。 確かにここでのシナリオは実行可能ですが、一般的な意味で扱うにはおそらく複雑すぎると思います。 現在の状況がまったく問題ない場合が多いことがわかりますが、一部のアプリケーションでは問題になる可能性があります。 とにかく、ほとんどの場合、特定のセッションに対して実行中のリクエストは1つだけだと思います。

実際、これはどのWebリソースにも存在する問題です。情報に基づいて、GETの後にPUTを実行した場合も同じことが起こりますが、その間に状況が変わった可能性があります。

とにかく、それは現時点での私の考えですが、さらに議論できてうれしいです。

長期的には、これはアプリケーションドメインの問題のようです。

clessが投稿したシナリオを考えると、リクエスト1が十分に長く実行されてリクエスト2が並行して発生する可能性がある場合（たとえば、Angular.jsで記述されたシングルページアプリケーション、またはいくつかのAPIにヒットする非同期Node.jsアプリ）、長時間実行されるリクエストはセッションから切り離し、その時点で独立したワーカープロセスと見なす必要があります。

もちろん、これは問題に直接対処するものではありませんが、kisielkが述べたように、あらゆる種類のロックを実行すると、限界的なケースのように見えるものに多くのオーバーヘッドが追加されます。

これは、セッションの競合状態の影響の実際の例です。 バグはデバッグが難しく、一見ランダムに表示され、開発者とユーザーの両方にとって迷惑です。 ajaxを多用する十分に大きなアプリケーションを考えると、これらの競合状態は遅かれ早かれ現れるでしょう。
http://www.hiretheworld.com/blog/tech-blog/codeigniter-session-race-conditions
http://www.chipmunkninja.com/Troubles-with-Asynchronous-Ajax-Requests-g@

同様の問題を扱っているEllisLab / CodeIgniter＃1746のスレッド全体を読みましたが、CodeIgniterが時々セッションIDを強制的に再生成するという事実によって問題が複雑になり、そこでの議論のほとんどはこの事実を中心に展開しています。

互換性のない方法でセッションを変更したり、既存のアプリケーションを壊す可能性のあるAPIに微妙な違いを導入したりすることに抵抗があることを理解しています。 ただし、オプションのロックが必要だと思います。 次のようにストアAPIに2つの関数を追加するのはどうですか。

type Store interface {
    Get(r *http.Request, name string) (*Session, error)
    New(r *http.Request, name string) (*Session, error)
    Save(r *http.Request, w http.ResponseWriter, s *Session) error
    Lock(r *http.Request, name string) error
    Release(r *http.Request, name string) error
}

これらの関数の使用は完全にオプションであり（セッションに書き込むすべての要求をロックすることを個人的に推奨しますが）、既存のアプリケーションに影響を与えることはありません。

提案されたロックインターフェイスには問題があります。ロックがMySQLなどのデータベースに保持されていて、ロックを取得した後にデータベース接続が切断された場合、ロックを解放することはできず、セッションは事実上デッドロックされます。 ロックは何らかの方法で期限切れになるはずですが、それが開発者にどのように公開されるべきか完全にはわかりません。

申し訳ありませんが、投稿したときにBojの返信を見逃しました。
長時間実行される要求は、競合状態をトリガーするための要件ではないことに注意することが重要です。 私のテストケースでの500ミリ秒のスリープは、競合状態がトリガーされることを確認するためだけにあります。 現実の世界では、これらの競合状態は「短い」要求でも発生しますが、頻度は低くなります。そのため、デバッグが困難になります。

また、高負荷では、短いリクエストでも実行に時間がかかる場合があることに注意する必要があります。

@cless良い点。

私はあなたの提案されたインターフェースの変更が好きです。

ロックの有効期限はRediStoreに比較的簡単に実装できます。Redisには、キーにTTLを設定できるEXPIREコマンドがあります。

この種のきめ細かいロックは、多くの種類のセッションストアにとって依然としてかなり非効率的ではないでしょうか。 そして、有効期限も問題です。

問題の一部は、セッションが長く存在していても保存が成功する可能性があることです。そうでない場合、問題の解決に大いに役立つのではないでしょうか。

@kisielk 、非効率な店舗の例を挙げていただけますか？ ほとんどのKey-Valueデータベースには、ロックを作成できる何らかの形式のアトミック操作があります。 SQLデータベースは通常、行ベースのロックにアクセスできます（ただし、ここでの詳細についてはよく知らないと言わざるを得ません）。
redisのようなKey-Valueストアのロック方法では、データベースへの複数のラウンドトリップが必要ですが、おそらくそれがあなたの意図したことですか？
goはファイルロックにアクセスするためのクロスプラットフォームの方法を提供しないため、ファイルシステムストアに問題があります。 cgoを使用すると、メインプラットフォームをサポートするプラットフォームを作成できると思いますが、それはおそらく回避するソリューションです。

現在のセッションを削除し、セッション固定を防ぐために新しいセッションに置き換えることについて話しているのでない限り、セッションが存在しなくなったときに保存することは実際の問題ではないと思いますが、正直なところ、それはまったく別の問題です。

@boj 、問題は、プログラマーが保存を試みる前に、ロックがまだ期限切れになっていないことを確認するための何らかの方法が必要なことです。 ロックの有効期限はどのくらいにする必要がありますか？

これはそれを実行するための1つの可能な方法ですが、私はそれがとても好きかどうかはわかりません。 あなたは時計が突然前進したり後退したりしないことに依存しており、それは安全な仮定ではありません：

func Lock(expiration time.Duration) time.Time {
    // Block here until the lock becomes your. Set the lock to expire after
    // dur+50ms. This extra 50 ms ensures that you never assume you own an
    // expired lock
    return time.Now().Add(expiration)
}

func main() {
    end := Lock(1000 * time.Millisecond)

    // Do your thing here ...
    // time.Sleep(1100 * time.Millisecond)

    if time.Now().After(end) {
        fmt.Println("Lock expired, throw an error")
    } else {
        fmt.Println("Good to go, save the session")
    }
}

@clessあなたのコメント全体は、 @ kisielkの心配事のように思われることを

提案したようにゴリラ/セッションのインターフェース部分を実装するのは非常に簡単かもしれませんが、同じように簡単にロック/リリースを実装しない限り、バックエンドを簡単に交換できる場合とできない場合があるシナリオを作成しますそして効率的な方法。 あなたが提案するものに関しては、どうやら多すぎるようです。何よりもまず、「バックエンドはハックのプログラミングに頼らずにこれを実装できますか？」、続いて「FileSystemStoreからFooBarStoreにスワップしようとしましたが、そうではありません。 Lock / Releaseを実装しているようで、プログラムが期待どおりに動作しません。」

セッションごとのロックの微妙な違いについての良い記事がここにあります：

http://thwartedefforts.org/2006/11/11/race-conditions-with-ajax-and-php-sessions/

ここですでに結論を出しているように、何か問題が発生した場合のロックのタイムアウトは、この種のスキームを実装する際の主要な問題の1つです。 これにはさらに検討が必要であり、バックエンドに大きく依存します

Lock / Releaseを実装する限り、個別のインターフェイスを使用することで、セッションごとのロックの実装をオプションにすることができます。 その後、バックエンドをそのインターフェイスに対してアサートできます。バックエンドが実装されていない場合は、メモリ内ロックを使用してデフォルトの実装を提供できます。

もちろん、もう1つの問題は、ライブラリのユーザーがロックとリリースを使用するようにコードを更新する必要があることですが、それがなければ、現在と同じ動作になると思います。

「メモリ内ロックを使用してデフォルトの実装を提供できます」

これは、リクエストが負荷分散されているマルチサーバー環境では意味がありません。

セッションを使用する既存のコードの動作を変更せずに正しく実装できるため、ロック用にまったく異なるインターフェイスを提供するというアイデアが気に入っています。

@bojが指摘したように、データベースストアに意味のある方法でメモリロックを提供することはできません。 ロック機能を提供する負担は、おそらくストア開発者にあるはずです。 ロックインターフェイスがない場合でも、セッションがロックインターフェイスを使用しようとするとエラーが返される可能性があります。 これは実際には問題にはならないはずです。デフォルトのストアがロックを提供する場合、他の開発者がそれに追随し、ユーザーは、たとえあったとしても、最小限の不便を感じるでしょう。

一部のストアではメモリロックがまだ意味をなす可能性があり、 FilesystemStoreがそれらの候補として適していると思います。 現実的には、負荷分散された状況でファイルシステムストアを使用することはありません（理論的にはネットワークファイルシステムで可能ですが）。 ファイルシステムロックは望ましいように思われますが、クロスプラットフォームを外出先で実装するのは難しいようです。さらに、NFSでの動作も保証されていません。

@boj ：同意しましたが、 @ clessが指摘しているように、それはあなたが持っている店の種類に基づいています。 FilesystemStoreは、セッションストアの同時変更を防ぐために、すでにRWMutexに依存しています。 ほとんどのバックエンドは実際には少なくとも最終的にはロックインターフェイスを実装すると思いますが、デフォルトを設定すると、開発者はそれまでの間、単一サーバー環境に適したリリースを行うことができます。 FilesystemStoreは、Goライブラリのクロスプラットフォームロック状況が改善されるまではその1つです。

私は@clessに完全に同意し、セッションロックの重要性を強調したいと思います。成熟したプラットフォーム（PHPなど）はセッションストアに実装します。 ファイルでは、「flock」システムコールを使用し、memcacheでは、「add」操作の戻り値と、「。lock」サフィックスと有効期限が設定された追加のキーを使用します。 また、 @ kisielkが新しいインターフェイスを使用するというアプローチにも同意します（関数「Lock」と「Release」を使用するのは理にかなっています。これを使用できますか？Goは、高いパフォーマンスと信頼性を実現するための言語です。私はたとえば、いくつかの実装（FileSystem、Redis、Memcache）に貢献する用意があります。いくつかの新しい構成オプションが必要であることに注意してください。

• spinLockWait：ロックを取得する試行の間にスリープするミリ秒（デフォルト：150）
• lockMaxWait：ロックを待機する秒数（デフォルト：30）
• lockMaxAge：自動的に解放される前にロックを保持できる秒数（デフォルト：lockMaxWait）

この問題は、最近の更新が確認されていないため、自動的に古いものとしてマークされています。 数日で自動的に閉鎖されます。