Wie kann man einen Java EE-Datenbank-Audit-Protokoller Multi-Thread?

Question

Ich arbeite an einer Java EE 5-Anwendung, die auf WebSphere 7.0 ausgeführt wird. Gibt es bekannte Methoden zur sicheren und effizienten Multi-Thread-Audit-Protokollierung in einer Java EE-Anwendung?

Wenn Sie Hintergrundinformationen benötigen: Die App ist ein Webdienst und jede Anforderungsnachricht, die Ergebnisse bei der Erstellung von 100 oder 200 Prüfprotokollnachrichten empfangen, die in einer Datenbank bestehen müssen. Ursprünglich wurde die Prüfungsprotokollierung mit einer benutzerdefinierten Prüfungshandlerklasse durchgeführt, die java.util.logging.handler erweitert, und die Veröffentlichungsmethode würde eine Datenbankverbindung öffnen, eine vorbereitete Anweisung aus dem Leiter ausführen und den Einfügen ausführen. Da dieser benutzerdefinierte Handler im Thread des EJB ausgeführt wurde, konnte die Prüfprotokollierung für jede Anforderungsmeldung zu mehreren Sekunden zur Antwortzeit addieren und SLAs übersehen.

Der Prüfungshandler wurde also durch einen Wrapper -Handler ersetzt, der ein separates Faden erstellt (Ja, mit neuem Thread () gegen die Regeln von Java ee). Der Wrapper -Handler verwendet einen Vektor, um die Audit -Datensätze zu stapfen, und es bleibt sie mit dem Prüfungshandler so schnell wie möglich im separaten Thread bestehen.

Während es die Regeln des Java ee -Threading durchbricht, hat diese Wrapper ziemlich gut funktioniert ... bis wir gleichzeitige Aufrufe auf dem MDB zugelassen haben. Der Wrapper kann es vermasseln, wenn mehrere EJB -Aufrufe zulässig sind, und speichert möglicherweise jeden Protokolldatensatz mehrmals in der Datenbank. Dies scheint darauf hinzudeuten, dass die Logik der Wrapper oder der Thread -Erstellung einen Fehler hat.

Ich wollte daran arbeiten, dieses Problem zu identifizieren und zu beheben, aber ich dachte, ich würde es zuerst fragen, ob es einen besseren Weg gibt.

Answer 1

Legen Sie diese Prüfungsnachrichten mit JMS in eine Warteschlange und rufen Sie dann einen anderen Dienst auf, der sie abholt und in der Datenbank speichert. Dies bedeutet natürlich, dass alle Protokolle nicht unbedingt in Echtzeit in der Datenbank gespeichert werden, aber dieser Ansatz lädt einige Arbeiten von WebSphere aus und Sie haben keinen Standard -Multi -Threading in Ihrem Code.