巧みに使うNameによるログの統一(完結編)

ミミミミミミミミミミミミミミ
ミミミミミミミミミミミミミミミミミミミミミミミNameによるログの統一
ミミミミミミミミミミミミミミミミミミミミミミミNameによるログの統一識別(続き)
ミミミミミミミミミミミミミミミミミミミミミミミNameによるログの統一(完結編)
ミミミミミミミミミミミミ中出しNetブロッキング
ミミミミミミミミミミミミミミミミミミミミミミミNameによるログの統一識別(java-logback編)
 
前の記事「巧みにCurrentThread.Nameを使用してログ記録を統一する(続き)」は、「巧みにCurrentThread.Nameを使用してログ記録を統一する」で、現在のスレッド名を使用してログを統一した後の問題です.csdnでも質問しましたが(here and here)、残念ながら原因は調べられませんでした.でも、@sp 1234兄貴の中肯の意見を楽しんでいます.
カスタム変数でパラメータを保存するなど、ビジネス向けに設計されたソフトウェアを設計します.これにより、この問題で異なるプロシージャが呼び出されたときに同じスレッドでも異なるスレッドでも、変数の値は一致します.もし「高大上」が技術的なレベルに達しすぎると、私たちは技術の底辺と問題を理解していないので、かえって巧みに下手になります.
もちろん、tmp 1コンストラクタで現在のスレッドのNameに値を割り当てるわけではありません.コード変更前はこのコンストラクタで宣言されたlogflagであるとしか言いようがないので,変更時に自然にこのコンストラクタで現在のスレッドに値を付与する.思いがけず、この問題にぶつかった.
ある学生は、ProcessRequestで現在のスレッドNameが取得できないのは、同じスレッドではないからではないかと質問したが、tmp 1でテストした.ashx.csクラスにプライベートオブジェクトを宣言し、コンストラクタで初期化し、ProcessRequestで取得できます.これにより、同じスレッドであると推定できるはずです.だから、どうして招待状の中の問題が現れて、確かに分析しにくいです.
ひとまず一つの思考問題に残しておきましょう.
 
最終的な解決策は,構築手法の代わりにProcessRequest手法で現在のスレッドに値を割り当てることである.

public abstract class HandlerBase : IHttpHandler
{
    protected readonly LogHelperUtil _LogHelperUtil;

    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "application/json"; 

        Thread.CurrentThread.Name = string.Format("[{0}_{1:HHmmssfff}_{2}]", this.GetType().Name, DateTime.Now, Guid.NewGuid().ToString().Replace("-", "").Substring(0, 5).ToUpper());
        _LogHelperUtil = new LogHelperUtil();
        
        ... ...

    }
}