Polling-транспорты в OSB - как настроить transaction timeout.

Получил вопрос от партнера, реализующего проект с использованием Oracle Service Bus. Суть проблемы в следующем: есть proxy-сервис на основе файлового транспорта, сервис получает файл и производит его обработку, причем обработка длится около 30 минут. Ровно через 10 минут после начала обработки сервис стартует заново, начиная обрабатывать тот же самый файл. Оставим за рамками данного поста обсуждение архитектуры решения, и попробуем разобраться в причинах подобного поведения OSB.
Polling-транспорты в OSB (file, ftp, e-mail) работают следующим образом:

• входящий файл/сообщение e-mail помещается в специальную JMS-очередь. 
• каждую  очередь слушает специальный Message Driven Bean (MDB) и инициирует новую XA-транзакцию и начинает выполнение активностей, указанных в Request Pipeline proxy-сервиса
• в случае возникновения ошибки или таймаута транзакция откатывается, сообщение из очереди не удаляется
• будет ли произведена попытка еще раз обработать данное сообщение - зависит от соответствующих настроек очереди

Рассмотрим на примере файлового транспорта:

• входящие файлы помещаются в очередь wlsb.internal.transport.task.queue.file, в Weblogic Console ее можно найти в Services->Messaging->JMS Modules->jmsResources.

• у  очереди есть свойство Redelivery Limit, определяющее количество попыток повторно доставить сообщение в случае ошибки/таймаута при первичной доставке. Для нашей очереди оно равно 1, то есть будет производиться попытка один раз повторно доставить сообщение

• MDB, слушающий данную очередь называется PolledMessageListenerMDBEJB и находится в составе Enterprise Application с именем File Transport Provider

• у PolledMessageListenerMDBEJB на вкладке Configuration есть свойство Transaction Timeout, значение по умолчанию = 600 секунд (как раз те самые 10 минут из вышеописанной проблемы).  

То есть для оперативного решения проблемы требуется увеличить Transaction Timeout для данного MDB с 10 минут до например 1 часа.  Но это тревожный звонок, в среднесрочной перспективе предлагается подумать, является ли архитектура решения оптимальной.