Проблема распространения транзакции - PullRequest
0 голосов
/ 06 февраля 2019

У нас недавно была очень неожиданная проблема в PROD, которую нам удалось воспроизвести, но у нас все еще нет четкого объяснения того, что ее вызывает, и, что более важно, как ее исправить.

Наша системаплатформа рабочего процесса поставщика, которая предлагает нам хуки для добавления нашего собственного поведения.Он работает на сервере приложений WebSphere и представляет собой смесь Camel, Spring и EJB.Изначально это был чистый EJB, но несколько лет назад поставщик добавил Camel с целью избавления от сервера приложений.

Теперь проблема:

Начало обработки - это маршрут Camel, которыйСделано с атрибутом PROPAGATION_REQUIRED .Частью обработки является локальный вызов метода EJB.Не существует явной настройки для любого из методов EJB, кроме управления контейнером.Это означает, что вызов EJB должен получить неявное значение REQUIRED .Часть вызова EJB - это изменение данных.Ссылка на EJB получается с использованием некоторого кода, подобного приведенному ниже:

String repositoryName = MBLLookupUtil.getInstance().getRepositoryName();
RepositoryInstanceFacadeHome facadeHome = MBLLookupUtil.getInstance().getRepositoryInstanceFacadeHome(
            repositoryName);
RepositoryInstanceFacade facade = facadeHome.create();

// Here is when the data change happens:
facade.doSomeWork();

Журналы приложений ясно показывают, что обработка EJB происходит в том же потоке, что и клиент.После выполнения вызова в вызывающем клиенте происходит больше работы, когда возникает исключение тайм-аута.

Мы ожидаем, что как данные изменятся на стороне клиента, так и те, которые изменились как часть вызова EJB, будут откатываться, однако данныеизмененный EJB, вызов остается зафиксированным, пока клиентская сторона (Camel) получает откат.

В контексте приложения Spring мы используем WebSphereUowTransactionManager, который является рекомендуемым IBM способом настройки менеджера транзакций:

<bean id="txManager" class="org.springframework.transaction.jta.WebSphereUowTransactionManager"/>

Будем очень благодарны за любые подсказки о том, что может вызвать это или как мы могли бы продолжить расследование.Заранее спасибо.

ОБНОВЛЕНИЕ:

Как рекомендовано в комментарии tomgeraghty3, я внес изменение в код, чтобы записать значение TransactionSynchronizationManager.isActualTransactionActive(), и в результате было true

ОБНОВЛЕНИЕ 2: Мы выяснили, в чем проблема, потратив часы на анализ декомпилированного кода поставщика.Распространение транзакции было настроено в файле application-context.xml, но оно также было перезаписано прямо в коде POJO с аннотацией @Transactional(propagation=REQUIRED_NEW).Мы доказали, что это была проблема, удалив класс POJO из jar поставщика и добавив один без аннотации с тем же пакетом в один из наших.Очень грязно только для того, чтобы доказать наше подозрение.

Теперь наша более сложная задача - убедить поставщика решить проблему.Надеюсь, что это просто ошибка, а не значительное изменение.

...