Si accedo UserTransaction quiere decir esto que utilizo 2 fase de confirmación o XA?
-
19-09-2019 - |
Pregunta
UserTransaction ut = lookup .... ut.beginTransaction (); saveToFooDB (); statelessEjb.transactionSupportedMethod (); // ahorra algo a la Foo DB saveToFooDB (); ut.commit ();
Si yo estaba haciendo lo anterior, entonces mi entendimiento es que no es una transacción XA, ya que no abarca a través de múltiples recursos (como DB además JMS). ¿Es correcta mi entendimiento?
Solución
Fuente de datos se puede configurar de dos clases:
- XA : se trata de la fuente de datos pueden participar en la distribución de las transacciones
- local : también llamada no-XA, no pueden participar en una transacción distribuida
El UserTransaction
se define en la especificación JTA que describen cómo coordinar el participante en una transacción distribuida.
El servidor de aplicaciones que implementa la especificación JTA sin embargo, es libre de hacer una gran cantidad de optimizaciones. Uno de ellos es el last-agent-optimization
, lo que permite que el último participante en la transacción distribuida para ser local . Un habitual confirmación se realiza a continuación, durante los últimos participantes. Si sólo hay un participante, entonces es siempre el caso.
En resumen:
- Si usted tiene más de un participante, XA y 2 fase de confirmación es necesario utilizar
- Si sólo hay un participante, más soporte para el servidor de aplicaciones de código de datos local y no utilice la fase de golpe completo 2 protocolo de confirmación.
Para ver Glassfish:
Editar
El apartado "ámbito de transacción" de glassfish documentación lo explica mejor que yo. Supongo que es el mismo para todos los servidores de aplicación.
A transacción local implica sólo una recurso no XA y requiere que todos componentes de la aplicación que participa ejecutar dentro de un proceso. Local optimización transacción es específica al gestor de recursos y es transparente para el Java EE aplicación.
En el servidor de aplicaciones, un JDBC recurso es que no sea XA si cumple con cualquiera de los siguientes criterios:
En la configuración de conexiones JDBC, la clase DataSource no implementa la interfaz javax.sql.XADataSource.
La caja de soporte global de transacciones no está marcada, o al recurso ajuste de tipo no existe o no es establecido en javax.sql.XADataSource.
Una transacción permanece local si el siguen siendo ciertas condiciones siguientes:
- se utiliza uno y sólo un recurso no XA. Si cualquiera que no sea XA adicional se utiliza de recursos, la transacción es abortada.
- No hay ninguna transacción importación o exportación se produce.
Las transacciones que involucran múltiples recursos o participante múltiple procesos se distribuyen o global actas. Una transacción global puede involucrar a un recurso que no sea XA si la última optimización agente está habilitado. De lo contrario, todos los recursos necesarios deben ser XA. El uso de este último entre el agente y la optimización propiedad se establece en true de forma predeterminada. Para obtener detalles sobre cómo hacer esto propiedad, ver Configuración de la Servicio transacción.
Si es un recurso único XA se utiliza en una transacción, de una sola fase de confirmación se produce, de lo contrario la transacción es coordinado con una confirmación en dos fases protocolo.
Otros consejos
Una vez que comience la UserTransaction y, a continuación, obtener una conexión con el recurso (por ejemplo, bases de datos) utilizando una conexión de fábrica que se declara ser-Xa de apoyo, significa que la conexión se convertirá en parte de la transacción XA. Además, no importa en absoluto si se está conectando a tipos simples o múltiples de recursos como JMS y base de datos.
Espero que ayude.
Nitin