Безопасно ли устанавливать Hibernate after_transaction в качестве режима освобождения соединения JTA при использовании Bitronix Transcation Manager?

Согласно документам Hibernate, в среде JTA режим освобождения соединения по умолчанию — after_statement, что означает, что после каждого оператора логическое соединение, находящееся в состоянии гибернации, освобождается.

Когда логическое соединение освобождается, вызывается метод Connection close(), и текущий ресурс удаляется из списка диспетчера транзакций.

Согласно RedHat руководству разработчика транзакций< /а>:

«Метод delistResource используется для отделения указанного ресурса от контекста транзакции в целевом объекте. Сервер приложений вызывает метод с двумя параметрами:

An XAResources object, which represents the resource.
A flag to indicate whether the operation is due to the transaction being suspended (TMSUSPEND), a portion of the work has failed (TMFAIL), or a normal resource release by the application (TMSUCCESS)."

Поскольку Bitronix использует TMSUCCESS:

 currentTransaction.delistResource(xaResourceHolderState.getXAResource(), XAResource.TMSUCCESS);

Это означает, что соединение отключено от текущей ветки транзакций, и иногда вы можете получить зачисление 2 разных соединений для одного и того же адаптера ресурсов.

Я думаю, что удержание соединения до тех пор, пока выполняется транзакция, является лучшим выбором, поскольку мы обычно выполняем более одного оператора за транзакцию. Таким образом, режим выпуска after_transaction звучит более привлекательно.

Является ли режим выпуска after_transaction более подходящим для Bitronix? Кто-нибудь сталкивался с этим в производственной среде?


person Vlad Mihalcea    schedule 17.05.2014    source источник


Ответы (1)


Вы не должны видеть никакой разницы между after_statement и after_transaction, по крайней мере, с BTM. Теоретически after_statement является «более правильным», так как соединение и транзакция должны быть полностью независимыми в контексте XA, а соединение должно обслуживать несколько транзакций одновременно. На практике соединения и транзакции почти никогда не бывают независимыми, так как почти ни один ресурс не поддерживает это.

Пул соединений BTM реализует относительно сложный FSM, который позволяет изолировать транзакции в их соединении, в то же время повторно используя соединение, когда это возможно.

В контексте одной транзакции многократное получение соединения из пула с последующим его закрытием должно потреблять только одно соединение из пула: одно и то же соединение всегда должно откладываться пулом и использоваться повторно. Единственная причина, по которой я могу думать, что это приведет к тому, что два соединения будут потребляться из пула, - это если вы снова получите соединение, пока первое еще не закрыто. Любую другую причину, вероятно, можно считать ошибкой в ​​​​пуле соединений BTM.

person Ludovic Orban    schedule 22.05.2014
comment
Спасибо за ответ, Людовик. Дело в том, что мы собираемся запустить нашу систему в производство, и у нас не было времени протестировать ее с установленным флагом after_transaction. Из-за сложности Spring TM, оболочки Hibernate Transaction Logic и внутренней работы Bitronix очень сложно определить виновника. Хотя я видел 2 соединения, зачисленных в список, 2PC будут просто рассматривать их как всего 2 изолированных XAResources, поэтому атомарность TX гарантирована. Может быть, после запуска производства у меня будет больше времени, чтобы разобраться в этом. - person Vlad Mihalcea; 22.05.2014
comment
Когда я преследую такого рода проблемы, журналы отладки BTM неоценимы. Включите их и убедитесь, что вы настроили Mapped Diagnostic Context для отображения GTRID (см. docs.codehaus.org). /display/BTM/DebugLogging2x). Таким образом, вы можете легко отделить работу, выполняемую от имени каждой транзакции (например, путем разделения журналов для каждой транзакции с помощью простого grep), и довольно легко следовать логическому потоку пула соединений. - person Ludovic Orban; 22.05.2014
comment
Спасибо, обязательно попробую. Очень расстраивает, что мы никогда не могли изолировать проблему в модульном или интеграционном тесте. У меня есть тест системной интеграции, работающий с реальным производственным сервером, где я мог видеть эту аномалию, зарегистрированную в журналах. Когда я соберу информацию, я запутаю имена некоторых классов и опубликую их в сообщении о проблеме BTM, может быть, вы заметите какую-то аномалию потока. - person Vlad Mihalcea; 22.05.2014