¿Cómo se propaga UserTransaction?

Question

Tengo un bean sin estado con las transacciones de frijol gestionados, y un método como este:

@Stateless 
@TransactionManagement(TransactionManagementType.BEAN) 
public class ... { 

    @Resource 
    private UserTransaction ut; 
    @EJB 
    private OtherStatelessBeanLocal other; 

    public void invokeSomeMethods() 
     ut.begin(); 
     ... 

     // invoke other bean's methods here. 
     other.method(); 

     ... 
     ut.commit(); 

    } 

} 

Entonces, ¿cómo la UserTransaction propagan al bean OtherStatelessBeanLocal?

Answer 1

El objeto UserTransaction es un objeto proporcionado por el contenedor que envuelve el acceso a las llamadas API que utiliza el contenedor internamente, específicamente javax.transaction.TransactionManager. El TransactionManager tiene métodos como begin, commit, rollback y javax.transaction.Transaction getTransaction()

Bajo las cubiertas, la TransactionManager utilizará una técnica ThreadLocal o similar a realizar el seguimiento del estado de la transacción actual con el hilo. ThreadLocals son objetos muy simples que podrían describirse fácilmente como static HashMap que usa el nombre del hilo como la clave y un objeto de su elección como valor. Mientras permanezca en el mismo hilo, puede obtener el objeto desde cualquier punto de la cadena de invocación. Esta es una de las razones por las que no está permitido iniciar subprocesos en un entorno Java EE.

La propagación de seguridad funciona de manera similar, al igual que las búsquedas JNDI que mágicamente apuntan al espacio de nombre java:comp/env del módulo o componente correcto. En pocas palabras, no puede implementar un servidor de aplicaciones sin ThreadLocals. La propagación suena más activa de lo que es, cuando en realidad es simplemente el acto de no dejar el hilo para que el contenedor y todos los involucrados puedan encontrar sus "cosas".

De vuelta en términos de gestión de transacciones, el objeto que un TransactionManager rastreará en su ThreadLocal implementará (directa o indirectamente) las interfaces Transaction y TransactionSynchronizationRegistry. Entre estas dos interfaces, el contenedor tiene todos los ganchos que necesita para rastrear DataSource s, EntityManager sy otros recursos en la transacción actual en su nombre. Estas interfaces también permiten que el contenedor ofrezca devoluciones de llamadas como SessionSynchronization, así como medios para hacer otras cosas en su nombre al finalizar la transacción, como vaciar/cerrar EntityManagers, enviar mensajes pendientes de JMS y persistir los temporizadores creados por su aplicación en el curso. de la transacción.

Answer 2

Para EJB3 normalmente define la propagación de transacciones con la anotación @TransactionAttribute.

El atributo de transacción por defecto para todas las aplicaciones EJB 3.0 se requiere:

Si un cliente invoca el método del bean de empresa, mientras que el cliente está asociado con un contexto de transacción, el contenedor invoca el método del bean de empresa en el cliente de contexto de transacción.

del Departamento de Comercio para el tipo de transacción está aquí: http://download.oracle.com/javaee/6/api/javax/ejb/TransactionAttributeType.html

N. B. El contexto de persistencia y la propagación de transacciones suelen suceder juntas, pero no siempre, ¡cuidado! Por ejemplo, beans de sesión con estado pueden tener un extended persistence context.

Answer 3

Sobre la base de la especificación EJB, no se puede pasar de un contexto de transacción de un grano (en este caso su clase principal ...) utilizando la transacción programática en otro bean (en este caso, otros) utilizando la transacción programática