Как и в случае с производительностью, ответ таков: это зависит. В частности, это зависит от того, как именно вы используете драйвер.
Стоимость транзакционного взаимодействия с базой данных условно подразделяется на: издержки на сложность кода, накладные расходы на связь, обработку sql и дисковый ввод-вывод.
Коммуникационные издержки несколько отличаются между случаями XA и не-XA. При прочих равных условиях транзакция XA влечет за собой немного большую стоимость, так как требует большего количества обращений к БД. Для транзакции не-XA в режиме ручной фиксации стоимость составляет не менее двух вызовов: операция (ы) sql и фиксация. В случае XA это начало, операции sql, конец, подготовка и принятие. Для вашего конкретного случая использования, который будет автоматически оптимизирован для запуска, операций sql, завершения, подготовки. Не все вызовы имеют одинаковую стоимость: данные, перемещаемые в наборе результатов, обычно преобладают. В локальной сети стоимость дополнительных поездок туда и обратно обычно невелика.
Обратите внимание, что есть несколько интересных ошибок, ожидающих неосторожного. Например, некоторые драйверы не поддерживают подготовленное кэширование операторов в режиме XA, что означает, что использование XA несет дополнительные накладные расходы при повторном анализе SQL при каждом вызове или требует использования отдельного пула операторов поверх драйвера. Что касается пулов, то правильное объединение подключений XA немного сложнее, чем объединение не-XA-соединений, поэтому в зависимости от реализации пула подключений вы также можете столкнуться с небольшим ударом. Некоторые платформы ORM особенно уязвимы для накладных расходов пула соединений, если они используют агрессивное освобождение соединения и повторно запрашивают в рамках транзакции. Если возможно, сконфигурируйте захват и удержание соединения в течение всего времени жизни tx, вместо того, чтобы подключаться к пулу несколько раз.
С учетом оговорки, упомянутой ранее относительно кэширования подготовленных операторов, нет существенной разницы в стоимости обработки sql между XA и не-XA tx. Однако существует небольшое различие в использовании ресурсов на сервере базы данных: в некоторых случаях сервер может высвобождать ресурсы быстрее в случае не XA. Однако транзакции обычно бывают достаточно короткими, поэтому это не является существенным фактором.
Теперь мы рассмотрим издержки дискового ввода-вывода. Здесь мы имеем дело с вводом-выводом, вызванным протоколом XA, а не SQL, используемым для бизнес-логики, поскольку последний в любом случае не меняется. Для транзакций только для чтения ситуация проста: разумный менеджер БД и tx не будет делать никаких записей в журнале, поэтому нет никаких накладных расходов. Для случаев записи то же самое верно, когда db является единственным задействованным ресурсом из-за однофазной оптимизации фиксации XA. Для случая 2PC каждому серверу БД или другому менеджеру ресурсов требуются две записи на диск вместо той, которая используется в случаях не XA, а менеджеру tx также нужны две записи. Благодаря медленности дискового хранилища это основной источник снижения производительности в XA по сравнению с не-XA.
Несколько абзацев назад я упоминал о сложности кода. XA требует немного больше выполнения кода, чем не-XA. В большинстве случаев сложность скрывается в диспетчере транзакций, хотя вы, конечно, можете управлять XA напрямую, если хотите. Стоимость в основном тривиальная, с учетом оговорок, уже упомянутых. Если вы не используете особенно плохой менеджер транзакций, в этом случае у вас могут возникнуть проблемы. Случай только для чтения особенно интересен - провайдеры диспетчера транзакций обычно прикладывают усилия по оптимизации к коду дискового ввода-вывода, тогда как конфликт блокировок является более существенной проблемой для случаев использования только для чтения, особенно в высококонкурентных системах.
Обратите также внимание, что сложность кода в tx manager является чем-то вроде «красной сельди» в архитектурах с сервером приложений или другим стандартным провайдером менеджера транзакций, поскольку они обычно используют один и тот же код для координации транзакций XA и не-XA. В не XA-случаях, чтобы полностью пропустить tx-менеджер, вам обычно приходится указывать серверу приложений / фреймворку обрабатывать соединение как нетранзакционное, а затем напрямую инициировать принятие с использованием JDBC.
Таким образом, сводка : Стоимость ваших запросов sql будет доминировать во времени транзакции только для чтения независимо от выбора XA / non-XA , если только вы не ошибетесь что-то в конфигурации или выполнение особенно тривиальных операций sql в каждой передаче, причем последняя является признаком того, что ваша бизнес-логика может использовать некоторую реструктуризацию для изменения соотношения накладных расходов управления tx и бизнес-логики в каждой передаче.
В случаях, доступных только для чтения, применяется обычный совет, независимый от протокола транзакций: учитывайте кэш второго уровня с учетом транзакций в решении ORM, а не каждый раз обращайтесь к БД. В противном случае настройте sql, а затем увеличивайте буферный кэш базы данных, пока не увидите 90% + частоту обращений или не увеличите максимальные значения слотов ОЗУ сервера, в зависимости от того, что произойдет раньше. Беспокойтесь о том, что XA против не XA, когда вы это сделаете и обнаружите, что все еще слишком медленно.