Quiero saber cómo se implementa internamente la transacción en EJB. Quiero saber la lógica que usan para crear una transacción. si se puede señalar algunos artículos que serían útilescómo se implementa el concepto de transacción en EJB
Hibernate tiene TransactionFactory:
Una fábrica de resumen para las instancias de transacción. Las implementaciones concretas están especificadas por hibernate.transaction.factory_class.
Tiene implementaciones: JDBCTransactionFactory, JTATransactionFactory, CMTTransactionFactory. Estas fábricas crean una instancia de Transaction, por ejemplo JDBCTransaction.
Entonces no se puede decir lo que sucede por JTA y CMT, pero para JDBC es tan simple como poner la auto-entrega en false (cuando se llama a iniciar una transacción):
connection.setAutoCommit(false);
Y respectivamente en transaction.commit(): connection.commit()
Si alguna excepción se produce cuando se opera con la sesión, se invoca connection.rollback()
Hibernate no implementar tran sactions, se basa y envuelve transacciones JDBC o transacciones JTA (administradas por contenedor o administradas por la aplicación).
EJB En cuanto, si se quiere entender los detalles de un Gestor de transacciones JTA, tendrá que ser fluido con las interfaces JTA UserTransaction, TransactionManager y XAResource que se describen en el JTA specification. El JDBC API Tutorial and Reference, Third Edition también será útil para comprender la parte XA de un controlador JDBC.
Luego, obtenga las fuentes de un contenedor EJB (como JBoss) o de un Administrador de transacciones JTA independiente (como Atomikos) para analizar la parte TM. Y buena suerte.
gracias por la respuesta. Estaba hablando de la implementación de Transacción en el EJB o cualquier implementación de JTA. –
lo siento mucho, hay un error de Javascript en mi navegador. He votado por su respuesta. –
@Suresh Bueno, no hay problema. Pero debo admitir que me sorprendió porque 1. no hay nada de malo en mi respuesta 2. Me resulta difícil rechazar las respuestas a sus propias preguntas. Siéntete libre de revertirlo si fue un error. –
De EJB in Action libro
El protocolo utilizado para lograr los recursos múltiples es el de dos fases cometer. El protocolo de confirmación en dos fases realiza un paso preparatorio adicional antes del compromiso final. A cada administrador de recursos implicadose le pregunta si la transacción actual se puede confirmar con éxito. Si alguno de los administradores de recursos indica que la transacción no se puede comprometer si se intenta, la transacción completa se abandona (se retrotrae). De lo contrario, la transacción puede continuar y se les pide a todos los administradores de recursos que se comprometan.
Un administrador de recursos puede ser una base de datos, por ejemplo. Otros ejemplos incluyen un Servicio de mensajes. El componente que coordina las transacciones se llama Administrador de transacciones.
Supongamos que tiene una aplicación que implica dos bases de datos distintivas. ¿Cómo realiza el administrador de transacciones su trabajo utilizando el protocolo de confirmación en dos fases?
Hibernate se construye en la parte superior de la API JDBC. Simplemente coordina una base de datos. Así que si usted llama
session.commit();
Detrás de las escenas, se llama
connection.commit();
Si realmente quiere estudiar internos de transacción, mi consejo es Java Transaction Processing libro.
Esta pregunta podría tener respuestas en muchos niveles.
Una discusión general de lo que está pasando se puede encontrar here
Mi resumen es el siguiente ... En primer lugar, en algún lugar debe haber un coordinador de transacciones, el contenedor EJB estará al tanto de la coordinadora - normalmente eso es parte de el servidor de aplicaciones. Así que todo lo que el contenedor EJB tiene que hacer es llamar al
someobject.BeginTransaction()
eso es todo. La API real que utiliza el contenedor EJB es JTA. Los EJB realmente pueden usar Transacciones Transaccionadas de Bean o Transacciones Administradas de Contenedores. En el caso de Bean Managed, el implementador no debe realizar las llamadas de JTA. Usualmente usamos transacciones manejadas por contenedores (CMT). En cuyo caso, el contenedor tiene una lógica que se ejecuta antes de llegar a la implementación. Por ejemplo:
if (we're not already in a transaction)
begin transaction
call the EJB implementation
y más tarde el recipiente tiene lógica
if (finished processing request)
commit transaction
con otros caminos para abortar la transacción si han ocurrido errores.
Ahora que la lógica es más compleja porque los EJB CMT se anotan con las instrucciones de control de transacción. Por ejemplo, puede decir cosas "si ya tenemos una transacción, úsela". De modo que si un EJB llama a otro, solo se utiliza una transacción. Lea las especificaciones de EJB para eso.
Sin embargo, todo eso es bastante obvio en cualquier descripción de Java EE EJB. Así que sospecho que está preguntando sobre qué sucede dentro de las llamadas de JTA, cómo se implementa el administrador de transacciones y su relación con los administradores de recursos transaccionales (por ejemplo, las bases de datos). Ese es un gran tema. De hecho, hay implementaciones del protocolo de transacción distribuida XA. Francamente, dudo que realmente necesites saber esto. En algún momento, confías en las API que estás utilizando. Sin embargo, hay un detalle clave: su administrador de transacciones (generalmente el propio servidor de aplicaciones) debe poder decirle a los administradores de recursos el destino de cualquier transacción determinada, y esa información debe sobrevivir al reinicio del servidor de aplicaciones, por lo tanto, un almacén persistente de información de transacciones debe ser mantenido. Encontrará registros de transacciones en algún lugar, y al configurar el servidor de aplicaciones, debe asegurarse de que esos registros estén bien atendidos.
+1 por mencionar XA, ya que es el protocolo base habitual para los servicios de transacción J2EE. También se debe tener en cuenta que JTA es una especificación de interfaz, depende de otra persona (Wbelogic, Websphere, Oracle, JBOSS, etc.) para proporcionar la implementación real. –
¿Es "el implementador" el JTS? Al leer en la red, JTA es una "especificación" como las API de JDBC (analogía). En el contexto de JTA, he leído dos términos: JTA, JTS, ¿así que JTS es la implementación de JTA? – CuriousMind
No, JTS está preocupado por algunos detalles de implementación bajo JTA. Estrictamente hablando, una implementación de JTA podría no usar JTS, las especificaciones de JEE lo recomiendan pero no imponen el uso de JTS. JTS es una implementación para el OTS de especificaciones de transacciones de CORBA y se ocupa de las comunicaciones entre los administradores de recursos y los gerentes de transacciones. Claramente, si la implementación de JTA usa JTS, es probable que encuentre otros administradores de recursos que hablen ese protocolo, de ahí la razón por la cual JEE recomienda su uso. – djna
Otra buena lectura serían los artículos JTS de Brian Goetz; enlaces:
Y ¿cómo afecta esto a responder la pregunta de la OP? – talonx
@talonx la pregunta fue inicialmente sobre hibernación. Y mi respuesta lo explica: muestra cómo se implementa el manejo de transacciones. Y dado que EJB puede usar Hibernate como JPA, creo que es correcto. ¿Qué parte no te gustó? – Bozho
gracias por aclarar eso. Quizás el OP haya editado la pregunta, porque no veo ninguna referencia a Hibernate, en cuyo caso no es una pregunta específica de Hibernate. – talonx