0

オブジェクトをチェックし、session存在する場合は、そのオブジェクトを間接的に使用する別のメソッドを呼び出します。2 番目のメソッドは数ナノ秒でこのオブジェクトにアクセスしますが、オブジェクトが 2 つの呼び出しの間に正確に期限切れになる状況を考えていました。Sessionこのような問題を防ぐために、オブジェクトはコードからのすべての読み取りアクセスでその寿命を延ばしますか? そうでない場合、問題を解決する方法は?

取得したオブジェクトを最初のメソッドから 2 番目のメソッドに渡さない理由を説明すると、これは、Page内部に他の多くのパラメーターを保持する ASP.NET オブジェクトを 2 番目のメソッドに渡しているためです。それらを別々にすると、Page今は 1 つのオブジェクトを渡すだけですが、多くのパラメーターがあります。

4

3 に答える 3

1

心配しないでください、これは起こりません

私があなたの状況を理解しているなら、それはこのように機能します：

  1. 特定のページにアクセスする
  2. セッションがアクティブな場合、すぐに2番目のページにリダイレクトするか、最初のページで特定のメソッドを実行します。
  3. 2番目のページ/メソッドはセッションを使用します

最初のメソッド/ページと2番目のメソッド/ページの実行の間にセッションが期限切れになるのではないかと心配しています。

最初のページが処理を開始する直前にセッションタイマーがリセットされたため、基本的にこれは不可能です。したがって、最初のページにアクティブなセッションがあった場合、2番目のページ/メソッドにもアクティブなセッションがあります（処理が20分前に終了する限り-デフォルトのセッションタイムアウト期間）。

セッションはどのように処理されますか

セッションは、ページが処理を開始する前に、すべてのリクエストで実行されるHTTPモジュールによって処理されます。これは動作を説明します。HTTPモジュールに慣れていない場合は、IHttpModuleインターフェイスについて少し読むことをお勧めします。

于 2010-11-29T14:29:18.203 に答える
0

ここで何が問題なのか理解に苦しんでいますが、スレッドセーフを参照してもう一度試してみましょう。

スレッドの安全性の問題

これがスレッド セーフの問題である場合は、特定のセッション オブジェクトを作成するときにいつでもロックを発行できるため、オブジェクトを二重に作成することによって他の並列リクエストが問題に遭遇することはありません。

if (obj == null)
{
    lock (objLock)
    {
        if (obj == null)
        {
            obj = GenerateYourObject();
        }
    }
}

これまでにロックを使用したことがない場合は、MSDN のロックに関するドキュメントを確認してください。また、他の Web リソースも確認することを忘れないでください。

于 2010-11-29T16:06:11.897 に答える
0

あなたの質問を理解するのはかなり難しいです、IMHOですが、試してみます。

私が理解していることから、あなたは次のようなことをしています：

string helloWorld = string.Empty;
if (this.Session["myObject"] == null)
{
    // The object was removed from the session or the session expired.
    helloWorld = this.CreateNewMyObject();
}
else
{
    // Session still exists.
    helloWorld = this.Session["myObject"].ToString(); // <- What if the session expired just now?
}

また

// What if the session existed here...
if (this.Session["myObject"] == null)
{
    this.Session["myObject"] = this.CreateNewMyObject();
}

// ... but expired just there?
string helloWorld = this.Session["myObject"].ToString();

Sessionオブジェクトはページ要求と同じスレッドによって管理されると考えました。つまり、try/catch なしで使用するよりも、オブジェクトが存在するかどうかを確認する方が安全です。

私は間違っていました：

Cache オブジェクトの場合、本質的に複数のスレッド間でアクセスされるオブジェクトを扱っているという事実に注意する必要があります

出典: ASP.NET キャッシュとセッション状態ストレージ

また、Robert Koritnik の回答を注意深く読まなかったのも間違いでした。実際、この回答は質問に明確に回答しています。

実際、ページ要求中にオブジェクトが削除される可能性があるという警告が表示されます。ただし、寿命はページ リクエストに依存するため、リクエストがセッション タイムアウトよりも長くかかる場合にのみSession、セッション変数の削除を考慮する必要があることを意味します(Robert Koritnik による回答のセッションの処理方法を参照)。

もちろん、そのような状況は非常にまれです。しかし、あなたの場合、ページ要求が 20 分 (デフォルトのセッション タイムアウト) よりも長くかかる可能性があると確信している場合は、オブジェクトが存在するかどうかを確認した後にオブジェクトが削除される可能性があることを考慮する必要がありますが、本当に使う前に。

この状況では、明らかにセッション タイムアウトを増やすか、セッション オブジェクトにアクセスするときに try/catch を使用できます。ただし、私見ですが、ページ リクエストに数十分かかる場合は、Windows サービスなどの他の代替手段を検討して作業を行う必要があります。

于 2010-11-29T14:51:09.347 に答える