Comment multi-thread un enregistreur d'audit de base de données Java EE?

Question

Je travaille sur une application Java EE 5 fonctionnant sur Websphere 7.0, et essaie de trouver un moyen de multi-thread thread-safe et la persistance des performant enregistrements du journal d'audit de base de données. Y a-t-il des méthodes connues pour effectuer l'enregistrement d'audit multithread de façon sûre et efficace dans une application Java EE?

Si vous avez besoin d'informations de fond: l'application est un service Web, et chaque message de demande qu'il reçoit des résultats dans la création de 100 ou 200 messages du journal d'audit qui doit être persistaient à une base de données. A l'origine l'enregistrement d'audit a été fait avec une classe de gestionnaire d'audit personnalisé qui étend java.util.logging.Handler, et la publication méthode ouvrirait une connexion de base de données, remplir une déclaration préparée à partir du LogRecord et exécuter l'insert. Étant donné que cette coutume gestionnaire a été en cours d'exécution au sein du fil, la journalisation d'audit de l'EJB pourrait ajouter jusqu'à plusieurs secondes pour le temps de réponse pour chaque message de demande et a cause SLAs manquer.

Ainsi, le gestionnaire d'audit a été remplacé par un gestionnaire d'emballage qui ajoute crée un thread séparé ( oui, d'un nouveau fil (), contre les règles de Java EE ). Le gestionnaire d'emballage utilise un vecteur pour la file d'attente des dossiers de vérification, et il les persiste aussi vite que possible dans le thread séparé à l'aide du gestionnaire d'audit.

Bien qu'il brise les règles de filetage Java EE, cette enveloppe a bien fonctionné ... jusqu'à ce que nous avons permis invocations simultanées sur le MDB. L'enveloppe a le potentiel de bousiller lorsque plusieurs invocations EJB sont autorisés, et potentiellement sauvera chaque enregistrement de journal à la base de données à plusieurs reprises. Cela semble indiquer que la logique de création d'emballage ou de fil a un bug.

J'allais travailler sur l'identification et la fixation de ce problème, mais je pense d'abord demander donc s'il y a une meilleure façon.

Answer 1

Utilisation de JMS, mettre ces messages d'audit sur une file d'attente, puis invoquez un autre service qui les ramasser et de les stocker dans la base de données. Ceci, bien sûr, signifie que tous les journaux ne seront pas nécessairement stockés dans la base de données en temps réel, mais cette approche déchargera des travaux de Websphere et vous ne serez pas avoir filetage niveau de rupture à plusieurs dans votre code.