2

現在、現在の HttpContext を使用して LINQ データ コンテキストを格納する Web アプリがあります。コンテキストは、 Rick Strahl のブログごとに、ユーザーごとに現在のリクエストに対して永続化されます。

string ocKey = "ocm_" + HttpContext.Current.GetHashCode().ToString("x")  
Thread.CurrentContext.ContextID.ToString();

if (!HttpContext.Current.Items.Contains(ocKey))
{
    // Get new Data Context and store it in the HTTP Context
}

ただし、global.asax ファイルから実行される、HttpContext を持たないスクリプトがいくつかあります。 サーバーが「リクエスト」を行っているため、HttpContext.Current は NULLです。

データ コンテキストを格納するために使用できる同等のオブジェクトはありますか? 再作成やオブジェクトの取り付け/取り外しについて心配する必要はありませんか? プロセスの存続期間中、コンテキストを保持したいだけです。

更新しました：

現在、DAL ヘルパー クラスで静的変数を使用しようとしています。クラス内のいずれかのメソッドへの最初の呼び出しで、DataContext がインスタンス化され、静的変数に格納されます。プロセスの最後に、DataContext で Dispose を呼び出す別のメソッドを呼び出し、静的変数を NULL に設定します。

4

5 に答える 5

4

これらのスクリプト専用の静的変数を使用することはできませんか? それは と同じ寿命を持ちAppDomainます。並行性の問題については慎重に検討する必要がありますが、値を保持する最も簡単な方法のように思えます。

（確認したところ、 の 1 つのインスタンスをHttpApplication使用して複数のリクエストを処理できますが、それぞれが一度に 1 つのリクエストしか処理できません。これは、同時リクエスト処理のために複数のインスタンスが作成されていることを示唆しています。これは検証していませんが、インスタンス変数に保持するのは安全ではないように思えます。)

編集:ジョシュの答えは、これをスレッドごとにしたいことを示唆しています。私には少し奇妙に思えます。これらのイベントが多数発生していない限り、イベントが異なるスレッドで実行されるだけで、共有ビジネス全体が無意味になる可能性が非常に高いからです。本当にそのようなことが必要な場合は、HttpApplication上記の段落で説明した理由から、派生クラスでインスタンス変数を使用することをお勧めします:)

于 2009-03-31T19:37:48.760 に答える
1

Why not use the current HttpContext? The scripts in your global.asax file are all the result of a request coming into the server, so there should be a context associated with that request which you can grab.

I don't understand the need for generating the key based on the hashcode or the thread. There is going to be a separate instance of HttpContext for each request that comes in, and that instance is going to be specific to the thread that is processing the request. Because of that, the key is pretty much worthless when it's based on the instance of HttpContext and the thread.

Also, how do you dispose of the DataContext when you are done? It implements IDisposable for a reason, so I would recommend against a shared instance like this.

UPDATE

In the comments, it indicates that there is a timer that is running that is executing the scripts. Instead of the timer, I would recommend setting up a Scheduled Task which will call a webservice or predetermined page on the site which will perform the task. Then you will always have an HttpContext to work with.

于 2009-03-31T19:39:28.320 に答える
0

HttpContext.Current is a static method and should be available from anywhere as long as the code is executing within the context of a request.

In your case your not executing within the context of a request, You could look at using Application.Cache but I would caution against holding a DataContext open. I am not very famillar with linq to entities, so I could be wrong, but generally caching data base related items such as connections is bad.

I would also recommend that you consider moving the logic out of your global.asax and to a windows service. This would let you have more control over these tasks, for example you can shut them down seperatley of the web site.

Edit

As JS points out you could use a static variable. You could also define an instance variable marked with ThreadLocal attribute. This will give each thread its own copy of the variable, and can eliminate contention. Since you want each thread to have its own copy anyways.

于 2009-03-31T19:40:45.417 に答える
0

Is there a reason why these need to be handled the same way as the other DataContexts? It seems to me that if the context is only needed inside the event handling routine, you shouldn't need to keep it around. Especially if it is in Application_Start (as per your comment), I wouldn't bother caching it anywhere -- just use it locally and pass it to the other methods as needed.

于 2009-03-31T19:45:24.763 に答える
0

タイマーを作成するときに、状態パラメーターとして DataContext を設定します。コメントに投稿した情報に基づいて、あなたの DataContext は何よりもタイマーに関連しているようです。

また、異なるタイマーに同じ DataContext を使用しないでください。異なるタイマーからの変更が混在することになるためです。また、同じタイマー ロジックが 2 回実行されないように注意してください。

于 2009-04-01T00:27:38.347 に答える