Cómo multihilo un registrador de auditoría de base de datos Java EE?

Question

Estoy trabajando en una aplicación Java EE 5 se ejecutan en WebSphere 7.0, y estoy tratando de encontrar una manera segura para los subprocesos y performant a multihilo la persistencia de los registros de registro de auditoría de base de datos. ¿Existen métodos conocidos para llevar a cabo el registro de auditoría multi-roscado de forma segura y eficiente dentro de una aplicación Java EE?

Si necesita alguna información de fondo: la aplicación es un servicio web, y cada mensaje de solicitud que recibe los resultados en la creación de 100 o 200 mensajes de registro de auditoría que debe ser persistente a una base de datos. Originalmente, el registro de auditoría se llevó a cabo con una clase de controlador de auditoría personalizado que se extiende java.util.logging.Handler, y el método de publicar abriría una conexión de base de datos, llenar una declaración preparada de la LogRecord, y ejecutar el inserto. Desde esta costumbre Handler estaba corriendo dentro hilo del EJB, el registro de auditoría podría ser de hasta varios segundos en el tiempo de respuesta para cada mensaje de solicitud y se causando SLA se puede perder.

Así que el manejador de auditoría fue sustituido por un manejador de contenedor que añade crea un hilo separado ( sí, con el nuevo hilo (), en contra de las reglas de Java EE ). El controlador de envoltura utiliza un vector que hacer cola los registros de auditoría, y les persiste tan rápido como sea posible en el hilo separado utilizando el controlador de auditoría.

A pesar de que rompe las reglas de Java EE roscado, este contenedor ha funcionado bastante bien ... hasta que nos permitió invocaciones concurrentes en el MDB. La envoltura tiene el potencial de arruinar cuando múltiples invocaciones EJB están permitidos, y potencialmente salvará cada registro registro de base de datos a las múltiples veces. Esto parece indicar que la lógica envoltura o subproceso de creación tiene un error.

Me iba a trabajar en identificar y solucionar ese problema, pero pensé que primero pediría así que si hay una mejor manera.

Answer 1

El uso de JMS, poner esos mensajes de auditoría en una cola, y luego recurrir a algún otro servicio que va a recogerlos y guardarlos en la base de datos. Esto, por supuesto, significa que todos los registros no serán necesariamente almacenados en la base de datos en tiempo real, pero este enfoque descargar parte del trabajo de WebSphere y no tendrá múltiples subprocesos de ruptura estándar en el código.