Потоки и транзакция Jms
Я застреваю в следующем сценарии. Совет я на этом
Существует входящая Очередь существует Основное выполнение потока (Мы не используем Слушателя JMS) и выбираем сообщение от очереди и обрабатываем сообщение и запускаем другой поток sub для обработки снова.
Теперь проблема состоит в том, Как я могу обработать транзакцию в основном потоке и потоке sub также. которые означают, когда я обрабатываю сообщение в основном потоке, говорят, что некоторая ошибка доступа Базы данных происходит так, я хочу откатывать сообщение назад входящей Очереди. и если тот же отказ происходит в потоке sub, который был создан основным потоком, полученное сообщение должно откатывать входящей Очереди.
Я шел через Ссылку Spring JMS, Но они, разграничивают транзакцию только Слушателям JMS
Таким образом, Как я могу применить понятие транзакции в своем сценарии
Совет меня, Если бы у Вас есть какой-либо пример программы, совместно использует со мной.That был бы лучше для понимания понятий
2 ответа
Я думаю, вы попали здесь в трудную минуту. Мне кажется, что наличие двух потоков в одной транзакции чревато условиями гонки и другими опасностями - на самом деле я даже не уверен, что это возможно. API-интерфейс транзакций JTA, с которым я знаком, использует однозначное сопоставление потоков с транзакциями.
Почему вы не можете вместо этого создать пул потоков, каждый из которых берет сообщение из очереди и выполняет всю работу. Тогда нет необходимости создавать новую цепочку после получения сообщения . Вы получаете столь же хороший параллелизм и большую простоту.
Затем вы обнаруживаете, что фактически заново изобрели стандартные подходы Java. Так почему бы просто не использовать MDB?
Если я хорошо понимаю, у вас есть один основной поток, который извлекает сообщения и порождает другие потоки для их обработки.
JMS поддерживает наличие нескольких слушателей, которые одновременно получают сообщение транзакционным способом. На самом деле это одно из преимуществ JMS: вы можете осуществлять транзакционную одновременную доставку сообщений.
Поэтому я предлагаю вам использовать пул потоков, в котором у каждого потока есть свой слушатель. Поток извлекает сообщение и обрабатывает его в рамках одной транзакции, а затем зацикливается. Таким образом, если обработка не удалась, сообщение останется в очереди. У каждого потока есть слушатель, поэтому вам больше не нужен основной поток.
В противном случае попробуйте использовать компонент, управляемый сообщениями, и посмотрите, поддерживает ли Spring какую-то похожую концепцию.