Como em todas as coisas relacionadas ao desempenho, a resposta é:depende. Especificamente, depende exatamente de como você está usando o driver.

O custo de interação transacional com um banco de dados é dividido aproximadamente em:sobrecarga de complexidade de código, sobrecarga de comunicação, processamento sql e E/S de disco.

A sobrecarga de comunicação difere um pouco entre os casos XA e não XA. Tudo o mais sendo igual, uma transação XA carrega um pouco mais de custo aqui, pois requer mais viagens de ida e volta ao banco de dados. Para uma transação não-XA no modo de confirmação manual, o custo é de pelo menos duas chamadas:a(s) operação(ões) sql e a confirmação. No caso do XA é iniciar, operação(s) sql, terminar, preparar e confirmar. Para seu caso de uso específico que otimizará automaticamente para iniciar, operação(s) sql, finalizar, preparar. Nem todas as chamadas têm o mesmo custo:os dados movidos no conjunto de resultados geralmente dominarão. Em uma LAN, o custo das viagens de ida e volta adicionais geralmente não é significativo.

Observe, no entanto, que existem algumas pegadinhas interessantes à espreita dos incautos. Por exemplo, alguns drivers não oferecem suporte ao cache de instrução preparada no modo XA, o que significa que o uso de XA carrega a sobrecarga adicional de analisar novamente o SQL em cada chamada ou exige que você use um pool de instruções separado na parte superior do driver. Embora no tópico de pools, agrupar corretamente as conexões XA é um pouco mais complexo do que agrupar as não-XA, portanto, dependendo da implementação do pool de conexão, você também poderá ver um pequeno acerto. Algumas estruturas ORM são particularmente vulneráveis ​​à sobrecarga do pool de conexões se usarem liberação de conexão agressiva e readquirir dentro do escopo da transação. Se possível, configure para capturar e manter uma conexão durante a vida útil do tx em vez de acessar o pool várias vezes.

Com a ressalva mencionada anteriormente em relação ao armazenamento em cache de instruções preparadas, não há diferença material no custo do tratamento de sql entre XA e não-XA tx. No entanto, há uma pequena diferença no uso de recursos no servidor db:em alguns casos, pode ser possível que o servidor libere recursos mais cedo no caso não-XA. No entanto, as transações são normalmente curtas o suficiente para que isso não seja uma consideração significativa.

Agora consideramos a sobrecarga de E/S de disco. Aqui estamos preocupados com a E/S ocasionada pelo protocolo XA, em vez do SQL usado para a lógica de negócios, pois o último permanece inalterado em ambos os casos. Para transações somente leitura, a situação é simples:um gerenciador de banco de dados e tx sensato não fará nenhuma gravação de log, portanto, não há sobrecarga. Para casos de gravação, o mesmo é verdadeiro onde o db é o único recurso envolvido, devido à otimização de confirmação de uma fase do XA. Para o caso 2PC, cada servidor db ou outro gerenciador de recursos precisa de duas gravações de disco em vez daquela usada em casos não-XA, e o gerenciador tx também precisa de duas. Graças à lentidão do armazenamento em disco, essa é a fonte dominante de sobrecarga de desempenho em XA versus não XA.

Vários parágrafos atrás eu mencionei a complexidade do código. XA requer um pouco mais de execução de código do que não-XA. Na maioria dos casos, a complexidade está enterrada no gerenciador de transações, embora você possa direcionar o XA diretamente, se preferir. O custo é principalmente trivial, sujeito às ressalvas já mencionadas. A menos que você esteja usando um gerenciador de transações particularmente ruim, nesse caso você pode ter um problema. O caso somente leitura é particularmente interessante - os provedores de gerenciadores de transações geralmente colocam seu esforço de otimização no código de E/S do disco, enquanto a contenção de bloqueio é um problema mais significativo para casos de uso somente leitura, principalmente em sistemas altamente simultâneos.

Observe também que a complexidade do código no gerenciador de tx é uma espécie de pista falsa em arquiteturas que apresentam um servidor de aplicativos ou outro provedor de gerenciador de transações padrão, pois geralmente usam o mesmo código para coordenação de transações XA e não XA. Em casos não-XA, para perder totalmente o gerenciador de tx, você normalmente precisa dizer ao servidor/estrutura de aplicativos para tratar a conexão como não transacional e, em seguida, conduzir o commit diretamente usando JDBC.

Portanto, o resumo é:O custo de suas consultas sql vai dominar o tempo de transação somente leitura, independentemente da escolha XA/não-XA , a menos que você estrague algo na configuração ou faça operações sql particularmente triviais em cada tx, sendo este último um sinal de que sua lógica de negócios provavelmente poderia usar alguma reestruturação para alterar a proporção da sobrecarga de gerenciamento de tx para a lógica de negócios em cada tx.

Para casos somente leitura, a recomendação agnóstica de protocolo de transação usual, portanto, se aplica:considere um cache de segundo nível de nível com reconhecimento de transação em uma solução ORM, em vez de acessar o banco de dados todas as vezes. Caso contrário, ajuste o sql e, em seguida, aumente o cache de buffer do banco de dados até ver uma taxa de acerto de 90% + ou você maximizar os slots de RAM do servidor, o que ocorrer primeiro. Só se preocupe com XA vs. não-XA depois de fazer isso e descobrir que as coisas ainda estão muito lentas.