Как вы определяете, было ли соединение JDBC получено из управляемого источника JTA или прямого JDBC?

Question

Я использую API-интерфейс поставщика, чтобы получить соединение JDBC с базой данных приложения. API работает при запуске на сервере приложений или при работе в автономном режиме. Я хочу запустить серию операторов SQL в одной транзакции. Я в порядке с ними, возникающими в контексте транзакции JTA, если он существует. Однако, если это не так, мне нужно использовать методы демаркации транзакций JDBC. (Вызов этих методов в соединении JDBC, участвующем в транзакции JTA, вызывает SQLException.)

Поэтому мне нужно определить, связано ли соединение с данным источником данных JTA или если это просто прямое соединение JDBC.

Есть ли прямой способ сделать это определение?

Спасибо!

Answer 1

Даже если это прямой JDBC, вы можете включить транзакцию JTA. Проверка флага autoCommit НЕ поможет в этом отношении. Вы можете находиться в транзакции, распределенной или иным образом, при этом autoCommit устанавливается в false. autoCommit, установленный в true, скажет вам, что вы не находитесь в распределенной транзакции, но значение false означает, что вы не будете автоматически фиксировать ... это может быть в любой транзакции.

Я думаю, вам придется вызвать UserTransaction.getStatus() и убедиться, что он не равен Status.NoTransaction(). Это скажет вам, есть ли у вас транзакция JTA.

Answer 2

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

Но я думаю, что вы действительно должны изменить свой API зависеть от внешних операций исключительно , Если вы все еще хотите поддерживать простой JDBC, оберните его в отдельный API, который только начинает транзакцию.

Обновление: просто перечитайте свой вопрос и убедитесь, что вы не предоставляете API, но хотите использовать управляемое контейнером соединение. Но все-таки, можете ли вы просто поручить (как часть требований вашей заявки), что JTA будет действовать? Если нет, вы можете предоставить опцию конфигурации, чтобы вернуться к транзакциям, управляемым вручную. Для такой критической функции кажется разумным требовать правильной конфигурации (в отличие от попытки угадать, что будет уместно).

Answer 3

Что говорит thilo, имеет смысл.

В противном случае, не уверен, прямой путь, но я дам вам «взломать» путь

написать BAD SQL, которые вы знаете, будут давать исключение DB. Это приведет к трассировке стека. Из трассировки стека вы можете узнать, является ли это производным JTA или НЕ?