私は現在、イベント/アクティビティロギングシステムに取り組んでいます。これは、メソッドインターセプターを使用する側面として実装しています。現時点では、システム/フレームワークは各メソッドが1つのアクティビティであると想定していますが、アクティビティが複数のメソッド呼び出しにまたがるようにこれを拡張したいと思います。これを行うために頭に浮かぶ最初のアプローチは、関連するすべてのメソッド呼び出しにコンテキストを提供することです。ただし、これを行う方法は、すべてのメソッド呼び出しが単一のスレッド(Log4JのMDC / NDCなど)のコンテキスト内にある場合にのみわかります。複数のスレッドのコンテキストを提供する方法はありますか(おそらくコードがマルチスレッドを認識していなくても)?
3 に答える
「ロギング」については考えないでください。それはさらに基本的なことです。複数のスレッドによって実行されるアクションを同じコンテキストで処理する場合、各スレッドにどのコンテキストにあるかを認識させるために何を伝播しますか?
これに答えることができる場合、このコンテキストは、ロギングのためにMDC / NDCに配置する必要があるものです(おそらく、コンテキスト全体ではなく、そのコンテキストのいくつかの重要な情報)。
アプリケーションがそのような情報を持っていない場合、誰もがあなたのためにそれを判断する方法はありません。
編集:
セットアップをどのように実行するかについて、私はあなたにいくつかのアイデアを与えるかもしれません。それをさらに強化するためにAOPを使用することが適切であるかどうか、それはあなたのさらなる研究です:)
// Assume I have a ContextManager which Context is stored in thread local:
abstract class ContextAwaredJob implements Runnable {
public ContextAwaredJob() {
this.context = ContextManager.getCurrentContext();
}
public void run() {
ContextManager.setCurrentContext(this.context);
doRun();
}
protected abstract void doRun();
}
新しい「ジョブ」はこの親クラスを拡張する予定であり、これを別のスレッドで実行している場合、コンテキストは自動的にセットアップされます。(もちろん、デザインはかなり洗練されていますが、何が起こっているのかについての基本的なアイデアを与えてくれます)
クラスThreadLocal?これは、実際にはTLSの有効で妥当な使用法である可能性があるように思われます。つまり、既存のコードにコテキストを追加します。
私はInheritableThreadLocalに出くわしました。これは、私のコードで機能すると思います。これは、関連するすべてのスレッドが親/ルートスレッドから生成されることを前提としています(これは安全な前提だと思います)。