Como con todo lo relacionado con el rendimiento, la respuesta es:depende. Específicamente, depende exactamente de cómo esté usando el controlador.
El costo de interactuar transaccionalmente con una base de datos se divide aproximadamente en:sobrecarga de complejidad de código, sobrecarga de comunicación, procesamiento de sql y E/S de disco.
La sobrecarga de comunicación difiere un poco entre los casos XA y no XA. En igualdad de condiciones, una transacción XA conlleva un poco más de costo aquí, ya que requiere más viajes de ida y vuelta a la base de datos. Para una transacción que no sea XA en modo de confirmación manual, el costo es de al menos dos llamadas:la(s) operación(es) sql y la confirmación. En el caso de XA, es inicio, operación(es) sql, finalización, preparación y confirmación. Para su caso de uso específico que se optimizará automáticamente para iniciar, operación(es) sql, finalizar, preparar. No todas las llamadas tienen el mismo costo:los datos que se mueven en el conjunto de resultados generalmente dominarán. En una LAN, el costo de los viajes de ida y vuelta adicionales no suele ser significativo.
Tenga en cuenta, sin embargo, que hay algunas trampas interesantes que acechan a los desprevenidos. Por ejemplo, algunos controladores no admiten el almacenamiento en caché de declaraciones preparadas en modo XA, lo que significa que el uso de XA conlleva la sobrecarga adicional de volver a analizar el SQL en cada llamada, o requiere que use un grupo de declaraciones separado encima del controlador. En cuanto al tema de los grupos, agrupar correctamente las conexiones XA es un poco más complejo que agrupar las que no son XA, por lo que, dependiendo de la implementación del grupo de conexiones, es posible que también vea un pequeño problema. Algunos marcos ORM son particularmente vulnerables a la sobrecarga de agrupación de conexiones si utilizan una liberación de conexión agresiva y readquieren dentro del alcance de la transacción. Si es posible, configure para tomar y mantener una conexión durante la vida útil del tx en lugar de acceder al grupo varias veces.
Con la advertencia mencionada anteriormente con respecto al almacenamiento en caché de declaraciones preparadas, no hay una diferencia sustancial en el costo del manejo de sql entre XA y no XA tx. Sin embargo, existe una pequeña diferencia en el uso de recursos en el servidor de base de datos:en algunos casos, es posible que el servidor libere recursos antes en el caso de que no sea XA. Sin embargo, las transacciones normalmente son lo suficientemente cortas como para que esto no sea una consideración importante.
Ahora consideramos la sobrecarga de E/S del disco. Aquí nos preocupamos por la E/S ocasionada por el protocolo XA en lugar del SQL utilizado para la lógica empresarial, ya que este último no cambia en ninguno de los dos casos. Para las transacciones de solo lectura, la situación es simple:un administrador sensato de db y tx no realizará ninguna escritura de registro, por lo que no hay gastos generales. Para los casos de escritura, lo mismo es cierto donde la base de datos es el único recurso involucrado, debido a la optimización de compromiso de una fase de XA. Para el caso de 2PC, cada servidor de base de datos u otro administrador de recursos necesita dos escrituras de disco en lugar de la que se usa en casos que no son XA, y el administrador de tx también necesita dos. Gracias a la lentitud del almacenamiento en disco, esta es la principal fuente de sobrecarga de rendimiento en XA frente a no XA.
Varios párrafos atrás mencioné la complejidad del código. XA requiere un poco más de ejecución de código que no XA. En la mayoría de los casos, la complejidad está oculta en el administrador de transacciones, aunque, por supuesto, puede manejar XA directamente si lo prefiere. El costo es mayormente trivial, sujeto a las advertencias ya mencionadas. A menos que esté utilizando un administrador de transacciones particularmente pobre, en cuyo caso puede tener un problema. El caso de solo lectura es particularmente interesante:los proveedores de administradores de transacciones generalmente ponen su esfuerzo de optimización en el código de E/S del disco, mientras que la contención de bloqueo es un problema más importante para los casos de uso de solo lectura, particularmente en sistemas altamente concurrentes.
Tenga en cuenta también que la complejidad del código en el administrador de tx es algo así como una pista falsa en las arquitecturas que cuentan con un servidor de aplicaciones u otro proveedor de administrador de transacciones estándar, ya que generalmente usan el mismo código para la coordinación de transacciones XA y no XA. En los casos que no son XA, para perder el administrador de tx por completo, normalmente debe decirle al servidor/marco de aplicaciones que trate la conexión como no transaccional y luego impulse la confirmación directamente usando JDBC.
Así que el resumen es:El costo de sus consultas sql dominará el tiempo de transacción de solo lectura, independientemente de la opción XA/no XA , a menos que arruine algo en la configuración o realice operaciones sql particularmente triviales en cada tx, lo último es una señal de que su lógica de negocios probablemente podría usar alguna reestructuración para cambiar la relación entre la sobrecarga de administración de tx y la lógica de negocios en cada tx.
Por lo tanto, para los casos de solo lectura, se aplica el consejo agnóstico del protocolo de transacción habitual:considere un caché de segundo nivel de nivel consciente de transacción en una solución ORM en lugar de acceder a la base de datos cada vez. De lo contrario, ajuste el sql, luego aumente el caché del búfer de la base de datos hasta que vea una tasa de aciertos superior al 90% o maximice las ranuras de RAM del servidor, lo que ocurra primero. Solo preocúpese por XA frente a no XA una vez que haya hecho eso y haya descubierto que las cosas siguen siendo demasiado lentas.
