Жизненный цикл JCA ManagedConnection

Question

В настоящее время я разработал исходящий адаптер JCA (с поддержкой LocalTransaction), и у меня возникли проблемы с управлением подключением. Мой адаптер работает хорошо, за исключением того, что сервер (WebLogic 12c) не возвращает ManagedConnections в пул. Согласно JavaDoc, сервер должен вызвать ManagedConnection.cleanup(), чтобы повторно инициализировать соединение и вернуть его в пул, но это не так.

Когда я использую адаптер от EJB, сервер создает новый ManagedConnection, начинает новую транзакцию, фиксирует ее, но не вызывает метод ManagedConnection.cleanup() и не возвращает его в пул.

Ниже вы можете увидеть мои испытания боб:

@Stateless(mappedName = "TestingBean") 
@Local(value = TestingBeanLocal.class) 
@Remote(value = TestingBeanRemote.class) 
@TransactionManagement(value = TransactionManagementType.CONTAINER) 
@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW) 
public class TestingBean implements TestingBeanCommon{ 

@Resource(mappedName = "eis/myJCA") 
private MyDataSource dataSource; 

@Override 
public void performTestAction(String param1, String param2) { 
    MyConnection connection = dataSource.getMyConnection(); 
    connection.performAction(ActionFactory.getSomeAction(param1, param2)); 
} 
} 

После 10 вызовов я получаю следующее:

Got Начальный контекст javax.ejb.EJBException: EJB Исключение:; Вложенное исключение: java.lang.RuntimeException: javax.resource.spi.ApplicationServerInternalException: невозможно получить соединение для пула = "eis/myJCA", weblogic.common.resourcepool.ResourceLimitException: настроено максимальное ограничение (0) на номер потоки позволили ждать ресурса дотянулись бассейн эйс/myJCA

Как вы заметили, он использует новую транзакцию для каждого вызова (REQUIRES_NEW атрибута). Сначала сервер создает новый экземпляр ManagedConnection в 10 раз, а затем пул соединений достигает максимальной емкости.

Из трассировки журналов видно, что не происходит ни одного звонка ManagedConnection.cleanup(), и каждое соединение в пуле занято. Я прочитал спецификацию JCA и обнаружил, что адаптер может отправить событие жизненного цикла для слушателей с использованием функции обратного вызова, но любая попытка использовать эти обработчик событий обратных вызовов заканчивались новым Exception:

javax.ejb.EJBException: BEA1 -001471C1E76DE5A4E067; Вложенное исключение: weblogic.transaction.nonxa.NonXAException: java.lang.IllegalStateException: [Connector: 199175] Этот ManagedConnection управляется контейнером для его транзакционного поведения и был зачислен в транзакцию JTA контейнером; приложение/адаптер не должны вызывать локальный интерфейс запуска транзакции/фиксации/отката. Отклонить событие LOCAL_TRANSACTION_COMMITTED от адаптера. javax.ejb.EJBException: EJB Exception:; вложенное исключение: java.lang.IllegalStateException: [Connector: 199175] Этот ManagedConnection управляется контейнером для его транзакционного поведения и был зачислен в транзакцию JTA контейнером; приложение/адаптер не должны вызывать локальный интерфейс запуска транзакции/фиксации/отката. Отклонить событие LOCAL_TRANSACTION_ROLLEDBACK от адаптера.

Я полагаю, что WebLogic не ждет какого-либо события (возможно, я отправил неправильный?).

Итак, что я делаю неправильно? Как вернуть сервер обратно в пул?

UPD: Я обнаружил, что события соединения очень важны для сервера. Сервер управляет соединениями на основе информации о событиях, которые были отправлены слушателям, которые он регистрирует в ManagedConnection. Теперь я поддерживал события в своем адаптере, но WebLogic по-прежнему не хочет устанавливать соединения обратно в пул.В настоящее время я получаю следующие события в журналах:

1. LOCAL_TRANSACTION_STARTED
2. CONNECTION_CLOSED
3. LOCAL_TRANSACTION_COMMITTED

Он выглядит хорошо для меня (событие CONNECTION_CLOSED означает приложение закрыто соединение, я добавил закрытым способом, что отправляет это событие). Успешное завершение и отсутствие исключений. Кажется, что я отправил события в правильном порядке (ранее WebLogic выбрасывает исключения, но теперь перестает это делать), но сервер по-прежнему не возвращает соединения в пул.

Я смущен.

Answer 1

Кажется, что я переделал эту проблему. Когда я посмотрел в консоли WebLogic, я обнаружил, что экземпляры ManagedConnection имеют -1 активных обработчиков. Поэтому я решил прокомментировать MyConnection.close() вызов метода, который я добавил в свой тестовый компонент, чтобы отправить событие CONNECTION_CLOSED. После того, как эта цепочка была сделана, объединение пулов начало работать отлично. Я попытался изменить свой тестовый компонент и установить его атрибут транзакции NOT_SUPPORTED. После этого ManagedConnections в бассейне имел 1 активный обработчик. Поэтому я положил обратно MyConnection.close() линии и пул соединений снова начинает работать.

Я предполагаю, что отправка CONNECTION_CLOSED случается неправильно в случае распространения транзакции. Также я предполагаю, что метод ManagedConnection.close(), который отправляет событие CONNECTION_CLOSED, следует использовать в случае одной транзакции. Но мне кажется странным, что WebLogic не хочет очищать ManagedConnections и возвращает их обратно, если у них есть отрицательное количество активных обработчиков.

Большое спасибо за помощь.