3

大規模なアプリケーションを作成しましたが、問題が発生しました。

私は顧客をvirdirsで分けているので、顧客は常に異なるアプリケーションプールにいます。私はこれを利用して、session_startでdb接続文字列やその他のコンテキスト関連の静的変数を設定し、アプリ全体で利用できるようにしました。

今、私は作成しなければならなかったvirdirの量で過負荷になり（500を超え、急速に成長しています）、これらを1つ（または複数）のアプリケーションプールに移動する必要があると感じています。問題は、URLから取得した「セッションコンテキスト」をアプリ全体に渡さないことです。コンテキストを渡すためにアプリに変更すると、基本的にアプリを書き直す必要があります。

アプリドメイン全体ではなく、セッション（つまり、APIへの1回の呼び出し）にこのコンテキストを設定する方法はありますか？あなたの助けは大歓迎です！

コンテキスト例-dbconstr-顧客ログフォルダ

編集：コンテキスト情報をスレッドID（System.Threading.Thread.CurrentThread.ManagedThreadId）にリンクするテーブルを作成できるのではないかと考えていましたか？

4

1 に答える 1

1

「コンテキスト」とはどういう意味ですか？リクエスト/レスポンス/セッション情報を意味しますか？手動で渡す必要はありません。httpリクエストの処理中、ASP.Netフレームワークはそれらすべてを静的な方法で公開します。

var ctx = System.Web.HttpContext.Current;
var req = ctx.Request;
var rsp = ctx.Response;
var sess = ctx.Session;
var cache = ctx.Cache;

var myOtherFoos = ctx.Items;

ASP.Netアプリケーションでは、System.Webアセンブリへの参照を追加していれば、どこからでも静的なCurrent-Contextにアクセスできます。

その「コンテキスト」を意味するのではなく、リクエスト処理とともに渡す必要のある独自の追加情報を意味する場合、HttpContextのアイテムはまさにそのためのものです。これは、新しいリクエストごとに作成される新しいコレクションであり、単一のリクエスト処理中に物事を保持するための軽量のスクラッチパッドとして使用できます。キャッシュやセッションとは異なり、「アイテム」はリクエスト処理が終了した瞬間に蒸発するため、リークや他のリクエストとのデータの混合の心配はありません。選択するキーに注意してください。そこにあるフレームワークのものと衝突しないようにしてください:)

于 2013-03-28T00:26:11.700 に答える