EJB3 Propagación de Transacciones

Matt, la pregunta que haces es bastante clásica, creo que la solución de autorreferencia de Herval/Pascal es genial. Hay una solución más general que no se menciona aquí.

Este es un caso para transacciones de "usuario" EJB. Dado que se encuentra en un bean de sesión, puede obtener la transacción de usuario desde el contexto de la sesión. Así es como se verá su código con las transacciones de usuario:

// supposing processObjects defined on MyStatelessRemote1 and process defined on MyStatelessLocal1
@Stateless
@TransationAttribute(TransactionAttributeType.NOT_SUPPORTED)
public class MyStatelessBean1 implements MyStatelessLocal1, MyStatelessRemote1 {

    @Resource
    private SessionContext ctx;

    @EJB
    private MyStatelessLocal1 myBean2;

    public void processObjects(List<Object> objs) {
        // this method just processes the data; no need for a transaction
        for(Object obj : objs) {
            this.myBean2.process(obj);
        }
    }


    public void process(Object obj) {

        UserTransaction tx = ctx.getUserTransaction();

        tx.begin();

        // do some work with obj that must be in the scope of a transaction

        this.mgr.merge(obj);
        // ...
        this.mgr.merge(obj);
        // ...
        this.mgr.flush();

        tx.commit();
    }
}

Creo que la cosa es que cada frijol está envuelto en un proxy que controla el comportamiento transaccional. Cuando llamas de un bean a otro, vas a través del proxy de ese bean y el comportamiento de la transacción puede ser cambiado por el proxy.

Pero cuando un bean llama a un método en sí mismo con un atributo de transacción diferente, la llamada no va a través del proxy, por lo que el comportamiento no cambia.

Matt, por si sirve de algo he llegado exactamente a la misma conclusión que tú.

Los tipos TransactionAttributeTypes solo se tienen en cuenta al cruzar los límites de Bean. Al llamar a los métodos dentro del mismo bean TransactionAttributeTypes no tienen ningún efecto, no importa qué Tipos se pongan en los métodos.

Por lo que puedo ver, no hay nada en la especificación de Persistencia EJB que especifique cuál debe ser el comportamiento bajo estas circunstancias.

También he experimentado esto en Jboss. También le daré una oportunidad en Glassfish y le haré saber los resultados.

En caso de que alguien se encuentre con esto un día:

Para evitar dependencias circulares (permitiendo auto referencia por ejemplo) en JBoss use la anotación 'IgnoreDependency' por ejemplo:

@IgnoreDependency @EJB Yo mismo myselfRef;

Todavía no lo he probado (estoy a punto de hacerlo), pero una alternativa a inyectar una auto-referencia a través de la anotación @EJB es el método SessionContext.getBusinessObject(). Esta sería otra manera de evitar la posibilidad de que una referencia circular explote las cosas sobre usted, aunque al menos para la inyección de frijoles sin estado parece funcionar.

Estoy trabajando en un sistema grande en el que se emplean ambas técnicas (presumiblemente por diferentes desarrolladores), pero no estoy seguro de cuál es la forma "correcta" de hacerlo.

Creo que tiene que ver con el @TransationAttribute(TransactionAttributeType.Never) on method processObjects.

TransactionAttributeType.Nunca

Http://docs.sun.com/app/docs/doc/819-3669/6n5sg7cm3?a=view

Si el cliente se está ejecutando dentro de un transacción e invoca a la empresa método de bean, el contenedor lanza un Excepción remota. Si el cliente no está asociado con una transacción, el contenedor no iniciar un nuevo transacción antes de ejecutar el método.

Asumo que eres cliente el método processObjects del código del cliente. Debido a que probablemente su cliente no está asociado con una transacción, el método llama con TransactionAttributeType.Nunca es feliz en primer lugar. Luego llama al método process desde processObjects que aunque tenga el TransactionAttributeType.La anotación requerida no fue una llamada al método bean y la política de transacciones no se aplica. Cuando llamas a merge obtienes la excepción porque aún no estás asociado con una transacción.

Intente usar TransactionAttributeType.Requerido para ambos métodos bean para ver si funciona.

Tuve estos problemas circulares de dependencia que Kevin mencionó. Sin embargo, la anotación propuesta @IgnoreDependency es una anotación específica de jboss y no hay contraparte en, por ejemplo, Glassfish.

Dado que no funciona con la referencia EJB predeterminada, me sentí un poco incómodo con esta solución.

Por lo tanto, le di una oportunidad a la solución de bluecarbon, iniciando así la transacción interna "a mano".

Además de esto, no veo otra solución que implementar el proceso interno() en otro frijol que también es feo porque simplemente queremos perturbar nuestro modelo de clase para tales detalles técnicos.