Сценарий
Мы поставляем приложение Java EE как слой между унаследованным приложением, ориентированным на базу данных, и приложением Java SE в реальном времени, которое управляет физическими устройствами, чтобы блокировать или предоставлять доступ (например, электронные двери).
Приложение Java EE является локальным для клиента. Он управляет сервером приложений в своей локальной сети.
Все, что делает Java SE, основано на его внутренней памяти. Эта память обновляется приложением Java EE через сообщения JMS.
Приложение Java EE получает сообщения от приложений Java SE, эти сообщения являются критически важными, т.е. они не могут быть потеряны.
Как только Java EE получает эти сообщения, оно сохраняет их в базе данных.
Основная часть наших клиентов имеет один компьютер базы данных (не кластеризованный, не HA и т. Д.).
Наше приложение должно корректно обрабатывать сбои подключения к базе данных, и это так. Но это становится действительно бременем для нашего дизайна.
Каждый новый поток (MDB, EJB Timer или WebService) начинается с вызова проверки базы данных в специальном синглтоне ( т.е. , а не в @Singleton, поскольку мы используем EJB 3.0 ). Если соединение с базой данных не работает, Singleton блокируется (поэтому все остальные потоки ждут, пока не будет снята блокировка), останавливает все запущенные таймеры и продолжает пытаться подключиться к базе данных каждые пять секунд. Если сообщение JMS доставляется во время этого процесса, MDB будет удерживаться в замке Singleton, поэтому сообщение не будет использовано или потеряно.
Как только подключение к базе данных будет восстановлено, блокировка снимается, и таймеры запускаются снова. MDB могут свободно обрабатывать свои сообщения.
Архитектура решений выглядит следующим образом [ извините за плохой рисунок mspaint ]:
Почему?
Мы применяем этот подход, основанный на блокировке, потому что при каждом тестировании, которое мы выполняли, генерирование исключения или откат транзакции в MDB приводит к немедленной доставке сообщения. Счет повторной доставки суммируется очень быстро, и сообщение попадает в очередь неработающих сообщений (DMQ).
Нам нужно, чтобы это сообщение было обработано, как только будет установлено соединение с базой данных, чтобы его нельзя было перенаправить в DMQ.
Мечта
Мы мечтаем о мире, в котором можно прекратить использовать сообщения или обрабатывать любые другие запросы, пока не установится соединение с базой данных.
Как только мы обнаружим сбой базы данных, все приложение будет закрыто и сконцентрировано на одной маленькой вещи: узнать, когда резервная копия базы данных. Как только мы получим эту информацию, все приложение снова заработает.
Вопрос
Возможно ли иметь больший контроль над контейнером Java EE? Как остановка или запуск аннотированного MDB по желанию.
Или, возможно ли быть защищенным от ошибок базы данных более элегантным способом? (Учитывая, что сообщения JMS являются критически важными.)