Как создать многопоточное средство ведения журнала аудита базы данных Java EE? - PullRequest
5 голосов
/ 03 января 2011

Я работаю над приложением Java EE 5, работающим на Websphere 7.0, и пытаюсь найти поточно-ориентированный и производительный способ многопоточности сохранения записей журнала аудита базы данных. Существуют ли какие-либо известные способы безопасного и эффективного ведения многопоточного ведения журнала аудита в приложении Java EE?

Если вам нужна некоторая справочная информация: приложение представляет собой веб-службу, и каждый запроссообщение о получении приводит к созданию 100 или 200 сообщений журнала аудита, которые необходимо сохранить в базе данных.Первоначально ведение журнала аудита выполнялось с помощью пользовательского класса обработчика аудита, который расширяет java.util.logging.Handler, а метод publish открывает соединение с базой данных, заполняет подготовленный оператор из LogRecord и выполняет вставку.Поскольку этот пользовательский обработчик выполнялся в потоке EJB, ведение журнала аудита могло увеличивать время ответа на каждое сообщение запроса до нескольких секунд и приводило к пропуску SLA.

Таким образом, обработчик аудита был заменен оболочкойДобавляемый обработчик создает отдельный поток ( yes, с новым Thread (), против правил Java EE ).Обработчик оболочки использует Vector для постановки в очередь записей аудита и сохраняет их как можно быстрее в отдельном потоке с помощью обработчика аудита.

Несмотря на то, что он нарушает правила потоков Java EE, эта оболочка вполне работалахорошо ... пока мы не разрешили одновременные вызовы на MDB. Оболочка потенциально может испортиться, если разрешено несколько вызовов EJB, и потенциально сохранит каждую запись журнала в базе данных несколько раз.Похоже, это указывает на то, что в логике создания оболочки или потока есть ошибка.

Я собирался поработать над выявлением и устранением этой проблемы, но подумал, что сначала спрошу SO, есть ли лучший способ.

1 Ответ

3 голосов
/ 04 января 2011

Используя JMS, поместите эти сообщения аудита в очередь, а затем вызовите какой-нибудь другой сервис, который их заберет и сохранит в базе данных. Это, конечно, означает, что все журналы не обязательно будут храниться в базе данных в режиме реального времени, но этот подход отгрузит некоторую работу от Websphere, и у вас не будет стандартного нарушения многопоточности в вашем коде.

...