4

そのため、集中ロギング用の相関 ID を持つ共通の状態コンテキスト シングルトンを使用しています。目的は、プロセス全体を通して ID を追跡し、さまざまな層を関連付けることです。

状態コンテキストには、複数の dll と複数のユーザーがアクセスします。

マルチスレッドが登場すると、問題が発生します。

  1. プロセス 1 がユーザー 1 によって起動されました
  2. 相関 ID が {1} に設定されます
  3. DLL A は状態コンテキストにアクセスし、相関 ID {1} を取得します
  4. プロセス 1 が完了する前に、プロセス 2 がユーザー 2 によって起動されました
  5. 相関 ID が {2} に設定されます
  6. {1} のはずの相関 ID {2} を持つ最初のプロセス アクセス状態コンテキストからの DLL B

この問題をどのように解決しますか?

ロックが私たちの解決策であるとは思いませんか? 他のアイデアはありますか？

ここに図があります

        (S)->[  CorrelationID {get;set}  ]                  
               ^           ^            ^
    U1 <-->    |           |            |                 O  
    U2 <--> [DLLA] <-->  [DLLB] <-->  [DLLC]       <-->  | |
    U3 <-->         
            {Web}  <--> {Domain} <-> {Data Access} <--> {DB}

    (<--                 Process / Thread           -->    )

{} = 可能な DLL の例

各ユーザーのプロセスには 1 つの相関 ID が必要です

4

2 に答える 2

0

もしかして、ThreadLocal<T>? https://msdn.microsoft.com/en-us/library/dd642243%28v=vs.100%29.aspx

于 2015-09-28T20:48:04.743 に答える
0

多くの研究の後、私たちは解決策を見つけました。

.Net Framework でLogicalCallContext クラスを利用します。

したがって、LogicalCalContext クラスが行うことは、.Net Framework を利用することであり、スレッドをジャンプしたとしても、コールバックを保持することによってキー値をプールに保持します。

スレッド間でデータをフローする方法を学ぶ...

すべての NLog ログを WebAPI 内の元の要求に結び付けるアプローチ

投稿のコメントはSerilogも参照しているので、それを見てみたいと思うかもしれません.

于 2015-09-29T21:52:26.980 に答える