Wie löst man die Transaktionsprotokollierung in Java?

Ich möchte Folgendes erreichen:

Innerhalb einer Transaktion möchte ich mehrere Protokollnachrichten generieren. Diese Protokollmeldungen sollten nur geschrieben werden, wenn die Transaktion erfolgreich übergeben wurde. Wenn die Transaktion zurückgesetzt wird, dürfen die Protokollnachrichten nicht protokolliert werden.

Ich konnte nichts finden, um dies zu erreichen (mit Frühling, Winterschlaf, Atomikos), also schrieb ich diesen kleinen Wrapper (ich habe ein paar Convenience-Methoden weggelassen):

Was halten Sie von diesem Ansatz? Gibt es größere oder kleinere Fehler oder Probleme damit? Oder noch besser, gibt es dafür fertige Lösungen?

UPDATE:

Da ich auch JTA verwende, habe ich eine neue Idee. Würde die Implementierung des TransactionLoggers als Empfänger einer transaktionsbewussten Nachrichtenwarteschlange das Zeitproblem lösen oder würde es die Dinge nur noch komplexer machen?

UPDATE:

Ich denke, dass die Protokollierung in einer Datenbank und das periodische Schreiben von Protokolleinträgen aus dieser Datenbank in eine periodische Aufgabe, wie in den Kommentaren vorgeschlagen, eine sehr gute Lösung für dieses Problem ist:

PROs:

• Normale Implementierung leisten
• integriert sich in TransactionManager
• Protokolleinträge in den Protokolldateien können nach Zeitstempel
sortiert werden

CONs:

• Log-Dateien sind nicht auf dem neuesten Stand (abhängig vom Periodic-Task-Intervall)
• datenbankstrukturabhängig
• Die Protokollierung einfacher nicht transaktionaler Ereignisse wird dbconnection-abhängig
• wahrscheinlich ein größerer Overhead für die Gesamtprotokollierung

Hier sind die Vor- und Nachteile, die ich mit dem Wrapper sehe, den ich gepostet habe:

PROs:

• Datenbank- und Framework-unabhängig
• einfache Implementierung
• Protokolldateien sind immer auf dem neuesten Stand

CONs:

• Protokolleinträge in den Protokolldateien sind nicht nach Ereigniszeitstempel, sondern nach "transaction-completition" -Zeitstempel geordnet (lange Transaktionen führen zu sehr gemischten Protokolldateien.
• rollback() und commit() müssen "manuell" aufgerufen werden, was zu Programmierfehlern führen kann (und möglichem OutOfMemoryError, wenn das Aufrufen dieser Methoden vergessen wird)

Ich denke, eine Kombination dieser beiden, wie das Protokollieren von Protokollsätzen im "Wrapper" -Ansatz, ist wegen der möglichen inkonsistenten Protokolldateien (vergessene Protokolleinträge aufgrund eines Anwendungsabsturzes) schlechter als die Verwendung eines der beiden erwähnten Ansätze. .

Meine Entscheidung ist jetzt, meinen "Wrapper" zu behalten. Die folgenden Gründe sind für diese Entscheidung entscheidend (in der Reihenfolge ihrer Wichtigkeit):

1. Ich bevorzuge Protokolldateien, die über perfekt geordnete Protokolleinträge immer auf dem neuesten Stand sind
2. Lange Transaktionen sind in meinem Fall sehr selten
3. Ich kann die Verwendung von rollback() und commit() auf nur wenige Methoden reduzieren.
4. Diese Lösung existiert bereits jetzt.

Übrigens: Ich möchte mein Englisch verbessern. Also, wenn Sie irgendwelche Fehler in meinem Artikel bemerken, werde ich mich freuen, wenn Sie sie aufzeigen.

UPDATE:

Einfach ausgedrückt benutze ich es so:

Das ist immer noch nicht perfekt, aber im Moment scheint es mir eine "gute Lösung" zu sein. Der nächste Schritt wird Aspekte verwenden, um meine Transaktions-Methoden zu dekorieren.

UPDATE:

Ich füge das in meine Frage ein, weil ich mich schlecht fühlte, meine eigene Antwort zu akzeptieren, obwohl jemand anderes mich auf den Weg gebracht hat.

Ich verwende jetzt einen AOP-Ansatz im Wesentlichen mit dem folgenden Logger. (In meiner realen Anwendung habe ich mehr als einen Logger und alle diese Logger werden von einem benutzerdefinierten Singleton-Manager verwaltet.):

und dieser Aspekt: ​​

In meiner applicationContext.xml habe ich die folgenden Zeilen:

Das funktioniert bis jetzt gut.

PROs:

• Datenbank- und Framework-unabhängig
• einfache Implementierung
• Protokolldateien sind immer auf dem neuesten Stand
• rollback() und commit() werden automatisch nach jeder Transaktion
aufgerufen

CONs:

• (Log-Einträge in den Log-Dateien sind nicht nach Event-Timestamp sortiert, sondern nach "transaction-completition" -Zeitstempel. Ich denke, das ist kein großer Nachteil, da die DB-Aktionen wirklich stattfinden, wenn die Transaktion ausgeführt wird und die LogRecords einer Transaktion werden immer noch korrekt sortiert.)