Transacciones JTA o LOCALES en JPA2 + Hibernate 3.6.0?

Question

Estamos en el proceso de volver a pensar en nuestra tecnología y nuestras siguientes opciones (no podemos vivir sin Spring e Hibernate debido a la complejidad, etc. de la aplicación). También estamos pasando de 1,4 a J2EE Java EE 5.

pila Tecnología

1. Java EE 5
2. JPA 2.0 (sé Java EE 5 sólo admite JPA 1.0, pero queremos usar Hibernate como el proveedor JPA)
3. Hibernate 3.6.0 (ya tenemos un montón de archivos de HBM con tipos personalizados etc por lo que no quiere migrar ellos en este momento a la APP. esto significa queremos tanto JPA/hbm asignaciones de trabajo juntos y por lo tanto la Hibernate como el proveedor JPA en lugar de utilizar el defecto que viene con la aplicación Server)

ahora los problemas es que quiero seguir con las transacciones locales, pero otros miembros del equipo que desee usa JTA He trabajado con J2EE durante los últimos 9 años y he escuchado una y otra vez que la gente sugiere seguir con las transacciones locales si no necesito compromisos de dos fases. Esto no es solo por motivos de rendimiento, sino que la depuración/solución de problemas de una transacción local es mucho más sencilla que una JTA (incluso si JTA solo realiza una confirmación de fase única cuando es necesario).

Mi sugerencia es utilizar las transacciones locales de gestión de transacciones declarativa + resorte (HibernateTransactionManager) en lugar de JTA contenedor

quiero para asegurarse de que si estoy siendo paranoico o tengo un punto válido. Me gustaría saber qué piensa el resto del mundo Java EE. O por favor, avísenme un artículo apropiado.

Answer 1

JTA no significa compromisos de dos fases. Creo que es la combinación de controladores JTA y XA lo que hace posible los compromisos de dos fases.

Todavía recomendaría usar JTA y transacciones declarativas sobre incrustación de lógica de transacción en el código. Las transacciones se realizan mejor en forma orientada a los aspectos, a la primavera.

ACTUALIZACIÓN:

Con la información adicional que has enviado, estoy de acuerdo con su argumento. Recomiendo usar las transacciones declarativas de Spring y la clase HibernateTransactionManager.

Answer 2

Como Duffy ya se mencionó, JTA no es sinónimo de confirmación de 2 fases, que es algo que se realiza a través del protocolo XA.

En JBoss AS, por ejemplo, puede elegir explícitamente si desea que una fuente de datos determinada sea un xa-datasource o un tx-datasource. En ambos casos, las transacciones se gestionan a través de JTA.

En algunos casos, es posible que ya haya estado usando JTA sin saberlo. Si envía un mensaje JMS de forma transaccional o actualiza un caché transaccional en la misma transacción donde modifica algo en una base de datos, el administrador de transacciones cambia automáticamente al modo XA. La fuente de datos que representa su base de datos puede no ser XA, pero en una transacción XA, se permite que 1 recurso sea distinto de XA. Las actualizaciones de este recurso se realizan a través del last resource commit optimization.

Aunque siempre debe calcular los riesgos y probarse a sí mismo, quiero advertir contra el miedo infundado. XA parece ser una de esas cosas que nosotros, como desarrolladores, hemos tenido miedo. Hubo una interesante discusión en el foro de JBoss sobre esto recientemente: when to use xa-datasource.

El hecho es que XA podría haber sido una tecnología compleja con implementaciones de bajo nivel en el pasado, pero casi una década y media después de este FUD este podría no ser el caso más. Lo que era una gran empresa compleja en 1995 es su funcionamiento común de la tecnología de fábrica en 2011.

Compare esto con el miedo que alguna vez tuvimos con EJB, que ahora es completamente irrelevante, o el miedo a las máquinas virtuales (obviamente no es un problema para los programadores de Java), o cuando realmente está participando en esta industria durante mucho tiempo, el temor de hacer algo tan básico como las llamadas a funciones;)