Soy nuevo en JTA y son los gerentes de transacciones subyacentes. ¿Alguien puede explicar los pros/contras de cada uno de estos? Siéntase libre de agregar otros que no figuran en el título.Atomikos vs JOTM vs Bitronix vs?
Además, ¿los principales servidores de aplicaciones (WebSphere, JBoss, Glassfish) no tienen su propio administrador de transacciones compatible con JTA? En esos entornos, ¿seguirías usando estas implementaciones de terceros?
Soy nuevo en JTA y sus gerentes de transacciones subyacentes. ¿Alguien puede explicar los pros/contras de cada uno de estos? Siéntase libre de agregar otros que no figuran en el título.
administradores de transacciones independientes yo sepa incluyen Bitronix, SimpleJTA, Tyrex (muertos?), JOTM (utilizado en Jonas), GeronimoTM/Jencks (utilizado en Geronimo), JBossTS (utilizado en JBoss) y Atomikos.
Nunca los he probado todos extensivamente (y esto es lo que tendrías que hacer si tienes que elegir uno), así que no puedo proporcionar un pros/contra exhaustivo (y eso requeriría algo de trabajo). Pero aquí hay algunos enlaces:
Por si acaso, aquí es mi punto de vista muy personal:
Personalmente, me gustaría preseleccionar Atomikos y JBossTS y ponerlos a prueba si tengo que elegir uno.
Además, ¿los principales servidores de aplicaciones (WebSphere, JBoss, Glassfish) no tienen su propio administrador de transacciones compatible con JTA?
Por supuesto que sí, JTA es parte de la especificación Java EE, un servidor Java EE tiene que soportarlo.
En esos entornos, ¿seguiría utilizando estas implementaciones de terceros?
No, utilizaría el administrador de transacciones provisto (por simplicidad, soporte, etc.).
He probado Atomikos y JOTM con Jetty. Atomikos funcionó bien y lo recomiendo totalmente. Lo hice, p. pruebas unitarias automatizadas para probar transacciones distribuidas en mi aplicación y estas pruebas funcionaron bien.
En lo que respecta a JOTM, estoy bastante seguro de que falsifica el protocolo de confirmación de 2 fases al menos algunas veces. Tenía una base de datos PostgreSQL con las capacidades de confirmación en dos fases desactivadas y JOTM podía funcionar como si tuviera transacciones reales distribuidas. Los administradores de transacciones reales (por ejemplo, el implementado en GlassFish) informaron un error en tal caso.
Utilicé JPA2 con Hibernate 4 en mi aplicación si es que importa.
Interesante comentario sobre cómo JTOM falsifica el protocolo de confirmación de dos fases. Los administradores/controladores de JTA que se proporcionan con WebLogic también hacen lo mismo. Es mejor que los falsifiquen cuando se presentan con un archivo db que no lo admite (o lo tiene apagado). –
Por lo general, puede tener un solo recurso que no sea XA en una transacción XA. Si su gestor de transacciones reconoce esta situación, llamará a prepare() sobre los recursos XA. Si tiene éxito, puede llamar a commit() sobre todos los recursos involucrados en la transacción, incluido el recurso que no es XA. –
Sí, lo llaman el voto de calidad. El recurso no XA decide si todo funciona – stringy05
Gracias por esta útil respuesta. En ocasiones, para fines de prueba y demostración, nuestra aplicación debe ejecutarse en Jetty o Tomcat. ¿Atomikos y JBossTS seguirán funcionando en esos entornos? De hecho, ¿esa es la razón de estos administradores de transacciones de terceros? ¿Para obtener un buen soporte de transacciones fuera de un servidor de aplicaciones completo? – HDave
@HDave: los gestores de transacciones independientes son útiles cuando necesita soporte de transacciones globales (es decir, cuando maneja más de un recurso transaccional) y su entorno no ofrece soporte para esto (por ejemplo, una aplicación independiente, un contenedor de servlet). En tales entornos, usaría Spring para facilitar la configuración (y JBossTS y Atomikos cabrían). –
Jencks es, de hecho, un contenedor JCA que utiliza GeronimoTM como administrador de transacciones JTA ... – pgras