фиксация / откат транзакции не на адаптере канала интеграции Spring - PullRequest
0 голосов
/ 27 сентября 2018

Я использую пружинную интеграцию для настройки потока сообщений.Я читаю файлы из каталога и делаю с ними что-нибудь.На моем адаптере входящего канала я установил опросник, включающий диспетчер транзакций и фабрику синхронизации.Фабрика синхронизации отправляет каналы после фиксации и после отката в каналы, которые перемещают исходный файл в папку успеха или ошибки.Все это прекрасно работает.

Теперь проблема, при обработке некоторых файлов, может приводить к появлению новых сообщений, которые я хотел бы пройти по тому же процессу.Я не хочу, чтобы эти новые файлы были задействованы в транзакции исходного файла, но я хочу, чтобы они имели собственный транзакционный контекст.

Я пытался обработать эту кошку несколькими способами, чтобы заставить ее работать.Самое близкое, что я получил, - это создать новое сообщение и использовать шлюз для отправки на начальный канал (через асинхронный вызов для завершения транзакции) - однако, поскольку определение транзакции находится в файле inbound-channel-adapter,новые сообщения не получают поддержки транзакций, поэтому, независимо от того, проходят они или нет, они не помещаются в соответствующую папку.

Это правильная архитектура или шаблон, о котором я не знаюследует использовать?

(ps причина, по которой я не просто записываю новые файлы в исходный каталог, который запрашивает адаптер, заключается в том, что я хочу включить в них заголовок, который указывает на родительский файл. Поэтому ядолжен создать сообщение).

Любые мысли будут оценены.

1 Ответ

0 голосов
/ 01 октября 2018

Метод @MessagingGateway может быть отмечен @Async и @Transactional.Таким образом, вызов такого подпотока будет происходить в другом потоке с его собственной транзакцией.Или вместо @Async вы можете просто добавить propagation = Propagation.REQUIRES_NEW.Таким образом, подпоток начнет свою собственную транзакцию, а обертка будет приостановлена.

onCommit/onRollback Я бы реализовал с try...catch вокруг этого @MessagingGateway вызова.

...