2011-01-03 23 views
5

Estoy trabajando en una aplicación Java EE 5 que se ejecuta en Websphere 7.0, y estoy tratando de encontrar una forma segura y eficaz de realizar subprocesos múltiples para la persistencia de los registros de auditoría de la base de datos. ¿Existen métodos conocidos para realizar el registro de auditoría de subprocesos múltiples de forma segura y eficiente dentro de una aplicación Java EE?Cómo multi-hilo un registrador de auditoría de base de datos de Java EE?

Si necesita información general: la aplicación es un servicio web y cada mensaje de solicitud que recibe da como resultado la creación de 100 o 200 mensajes de registro de auditoría que deben conservarse en una base de datos. Originalmente, el registro de auditoría se realizó con una clase de controlador de auditoría personalizada que amplía java.util.logging.Handler, y el método de publicación abriría una conexión de base de datos, rellenaría una declaración preparada de LogRecord y ejecutaría la inserción. Dado que este controlador personalizado se ejecutaba dentro del hilo del EJB, el registro de auditoría podría agregar hasta varios segundos al tiempo de respuesta para cada mensaje de solicitud y provocaba que se perdieran los SLA.

Así que el controlador de auditoría se reemplazó con un controlador de envoltura que agrega crea una hebra separada (sí, con un nuevo Thread(), en contra de las reglas de Java EE). El controlador de envoltura usa un Vector para poner en cola los registros de auditoría, y los persiste lo más rápido posible en el subproceso separado utilizando el controlador de auditoría.

Si bien rompe las reglas de enhebrado Java EE, esta envoltura ha funcionado bastante bien ... hasta que permitimos invocaciones simultáneas en el MDB. El contenedor tiene el potencial de arruinarse cuando se permiten varias invocaciones de EJB, y potencialmente guardará cada registro de registro en la base de datos varias veces. Esto parece indicar que la lógica de creación de envoltura o hilo tiene un error.

Iba a trabajar para identificar y solucionar ese problema, pero pensé que primero le preguntaría si hay una mejor manera.

+0

¿qué quiere decir con invocaciones concurrentes en MDB? Tenemos un tipo similar de modelo, excepto el hecho de que en lugar de MDB usamos MessageListener de Spring. –

+0

La especificación de activación tiene una propiedad "Sesiones de servidor máximas" para especificar cuántos mensajes pueden manejarse simultáneamente por una sola ActSpec. Antes teníamos esto en 1, por lo que solo se manejaba 1 mensaje por servidor en un momento dado. Cuando aumenta ese número a> 1, múltiples mensajes son manejados por un servidor en un momento dado. –

+0

Parece que está utilizando WebSphere MQ. Las "sesiones de servidor máximas" parecen ser una propiedad exclusiva de WMQ y no de MDB. Así que te sugiero que lo publiques en el foro de MQ. –

Respuesta

3

Usando JMS, coloque esos mensajes de auditoría en una cola, y luego invoque algún otro servicio que los recoja y almacene en la base de datos. Esto, por supuesto, significa que no todos los registros se almacenarán necesariamente en la base de datos en tiempo real, pero este enfoque descargará algo de trabajo de Websphere y no tendrá un multihilo estándar en su código.

+0

Gracias, es una buena idea. Creo que intentaré una prueba de concepto para ver cómo maneja la carga. –

Cuestiones relacionadas