проблема фиксации транзакции в спящем режиме в среде с высоким уровнем параллелизма

Question

Я объясню мою проблему немного подробнее.- У меня есть следующие классы

1. jms слушатель, который будет прослушивать очередь и будет иметь исполнителя пула потоков Java 1.5 для делегирования сообщения потоку (т.е. классу RequestExeuctor).
2. RequestExecutor (это исполняемый класс), который будет обрабатывать запрос, получая объект уровня обслуживания
3. класс обслуживания (saveStudent (), getStudent ())
4. класс dao. (SaveStudent(), getStudent ())

Рассмотрим следующий сценарий.

Запрос 1: сообщение jms для сохранения ученика.

1. jms получил сообщениеи делегирован RequestExecutor для сохранения студента.
2. RequestExecutor вызывает ServiceLayer.saveStudent () и отправляет сообщение обратно в очередь (здесь уровень обслуживания имеет границу транзакции для всех методов).поэтому, когда сообщение отправляется в очередь, изменения еще не переданы в db.

Запрос 2 (этот запрос будет поступать через несколько миллисекунд): сообщение jms для получения ученика.

1. jms получил сообщение и передал его в RequestExecutor для получения студента (это новый поток).
2. Вызов RequestExecutor ServiceLayer.getStudent (), но здесь все изменения, сделанные в первом запросе, еще не обновлены в БД ивозвращает ноль.

Между этими двумя потоками существует некоторый промежуток времени (может быть, несколько миллисекунд).но здесь я могу видеть изменения в БД.но они не видимы для thread2.

Может кто-нибудь пролить свет на эту проблему.

Спасибо, Рамки.

Answer 1

Это именно такие проблемы, которые решает двухфазная фиксация. Запись в очередь JMS и сохранение в базе данных должны быть частью одной глобальной транзакции 2PC, так что обе операции выполняются или не выполняются. Это гарантировало бы, что второй поток получил сообщение JMS только тогда и только тогда, когда пользователь был сохранен в базе данных.

Серверы приложений Java EE предоставляют диспетчеры транзакций с поддержкой XA (двухфазная фиксация). Если вы не работаете внутри сервера приложений Java EE, вы можете интегрировать его в приложение, например, Bitronix, Atomikos или другие автономные менеджеры транзакций.

Answer 2

Похоже, что вы используете разные ресурсы (DB, JMS) для реализации бизнес-транзакции, но не синхронизируете транзакции ресурсов, то есть транзакции JMS и DB в разное время, что приводит к несогласованному состоянию системы.

Это стандартная архитектурная проблема.Стандартные решения включают:

1. Использование xa-транзакций.Если вы работаете в контейнере EJB, управляемые контейнером транзакции по умолчанию будут использовать xa-транзакции (если ресурсы поддерживают xa-транзакции).Если вы не работаете в контейнере EJB, вы можете использовать распределенный менеджер транзакций, такой как atomikos, для использования xa-транзакций.
2. Использовать только один ресурс, либо
   1. , используя только одинтранзакционный ресурс (база данных, отключение JMS) или
   2. с реализацией JMS используют одну и ту же базу данных для сохранения сообщений.IIRC, если ActiveMQ встроен в ВМ, он может повторно использовать соединение базы данных приложения для сохранения сообщений JMS, тем самым совмещая транзакции с базой данных.

Answer 3

Работают ли эти потоки на другой JVM?

У нас были похожие проблемы, когда один процесс в JVM фиксирует транзакцию в базе данных, а другой процесс в другой JVM не видит изменения, потому что он читаетзначение из него первого или второго уровня кеша.