5

私は Websphere 7.0 で実行されている Java EE 5 アプリケーションに取り組んでおり、データベース監査ログ レコードの永続性をマルチスレッド化するためのスレッド セーフでパフォーマンスの高い方法を見つけようとしています。 Java EE アプリケーション内でマルチスレッド監査ロギングを安全かつ効率的に実行する既知の方法はありますか?

背景情報が必要な場合: アプリは Web サービスであり、アプリが受信する各要求メッセージにより、データベースに永続化する必要がある 100 または 200 の監査ログ メッセージが作成されます。当初、監査ロギングは、java.util.logging.Handler を拡張するカスタム監査ハンドラー クラスを使用して行われ、publish メソッドはデータベース接続を開き、LogRecord から準備済みステートメントを取り込み、挿入を実行しました。このカスタム ハンドラーは EJB のスレッド内で実行されていたため、監査ログによって、各要求メッセージの応答時間が数秒長くなることがあり、SLA に違反していました。

そのため、監査ハンドラーは、別のスレッドを作成するラッパー ハンドラーに置き換えられました (はい、Java EE の規則に反して new Thread() を使用)。ラッパー ハンドラーは、Vector を使用して監査レコードをキューに入れ、監査ハンドラーを使用して別のスレッドで可能な限り高速に永続化します。

Java EE スレッド化の規則に違反していますが、このラッパーは非常にうまく機能していました... MDB での同時呼び出しを許可するまでは。 ラッパーは、複数の EJB 呼び出しが許可されている場合に失敗する可能性があり、各ログ レコードがデータベースに複数回保存される可能性があります。これは、ラッパーまたはスレッドの作成ロジックにバグがあることを示しているようです。

私はその問題の特定と修正に取り組むつもりでしたが、最初に SO にもっと良い方法があるかどうか尋ねてみようと思いました。

4

1 に答える 1

3

JMS を使用して、これらの監査メッセージをキューに入れ、それらを取得してデータベースに格納する他のサービスを呼び出します。もちろん、これはすべてのログが必ずしもリアルタイムでデータベースに保存されるとは限らないことを意味しますが、このアプローチは Websphere から一部の作業をオフロードし、コードに標準的なマルチスレッドを壊すことはありません。

于 2011-01-03T22:37:43.607 に答える