Источник данных XA с использованием ссылок Oracle DB в управляемых транзакциях Java EE Container

У меня есть следующая среда:

Приложение EAR в WebSphere 9, управляемые контейнером транзакции с использованием источника данных XA для базы данных Oracle 19c (назовем ее база данных A).

Проблема в том, что источник данных (в некоторых транзакциях), то есть база данных A, вызывает базу данных B через ссылку на базу данных (база данных B также является Oracle 19c).

Пул соединений получает сообщение об ошибке "Слишком много ссылок на базу данных используется" из-за двухфазной фиксации. Скажем макс. количество используемых ссылок на базу данных равно 4, если я обновляю экран в 5-й раз, я получаю исключение SQL.

Установка максимального количества используемых ссылок на базу данных в свойствах базы данных только отсрочит проблему.

Я не контролирую (с точки зрения приложения) закрытие ссылок на базу данных.

ATM мы установили источник данных не-XA, и все работает нормально, но через некоторое время нам нужно будет вручную обрабатывать транзакции, которые включают один источник данных и WebSphere MQ.

Есть у кого идеи или опыт по этой установке?

РЕДАКТИРОВАТЬ: я пытаюсь заставить это работать с JPA 2.0.


person Nikola    schedule 22.09.2020    source источник


Ответы (1)


У вас есть два варианта:

  1. Если не вы, то разработчики приложения должны убедиться, что ссылки на базу данных закрыты. Если ваше максимальное количество активных ссылок на базу данных равно 4, то в вашем приложении может быть только 4 активных сеанса/пользователя.
  2. Увеличьте разрешенное количество ссылок на базу данных

В этой статье более подробно описаны исправления и обходные пути.

person EJ Egyed    schedule 22.09.2020
comment
Спасибо за ответ. Я пытаюсь заставить это работать в среде Java EE 7, где JPA часто используется для связи с базой данных. Я не могу так просто закрывать ссылки на базы данных. Но я даже не знаю, что люди делают в такой ситуации, как моя - они не используют ссылки на базы данных или избегают источника данных XA? - person Nikola; 11.10.2020