Transaccionalidad en EJB 3.

Un metodo dentro de un EJB por si solo es transaccional, sin embargo en el desarrollo de aplicaciones empresariales normalmente se tiene el caso en el cual un metodo de EJB tiene otros metodos de negocio y entonces es cuando vienen los problemas, es decir un esquema como el siguiente:

Es decir cuando el metodo del EJB 1 usa metodos de los EJB 2 y 4, en una configuracion por omision pasa que cada metodo es transaccional es decir si el metodo del EJB 2 falla no necesariamente ocurre un rollback en el metodo del EJB 1.
Para solventar este tipo de problemas se hace necesario entender como funcionan los metodos EJB, por una lado tenemos que decirles a los metodos de  EJB 2 y el EJB 4 que deben estar unidos a una transaccion esto lo hacemos a traves de la siguiente anotacion:

@TransactionAttribute(TransactionAttributeType.MANDATORY)

Al hacer esto conseguimos que necesariamente deben estar unidos a una transaccion y esta transaccion debe ser iniciada en el metodo del EJB 1, esta accion la conseguimos al utilizar la anotacion

@TransactionAttribute(TransactionAttributeType.REQUIRES_NEW).

Haciendo estos pasos estamos indicando como funcionan las transacciones dentro de los EJB, sin embargo no es suficiente.
Nos hace falta entender otro comportamiento dentro de los EJB, y es que el contenedor distingue dos tipos de excepciones una de tipo aplicacion y una de tipo runtime, cuando lanzamos una excepcion tipo Exception el contenedor tiene marcado por omision que debe terminar con un commit a nivel de transaccion, cuando la aplicacion lanza una excepcion de tipo Runtime el contenedor la debe terminar con un rollback, esto quiere decir que cuando manejamos nuestras excepciones dentro de un bloque try y catch el contenedor por omision asume que independientemente de como se ejecute debe terminar con un commit, esto es un problema cuando manejamos nuestra  logica de negocio y esperamos que pase lo contrario.
Este problema lo solucionamos generando nuestras propias excepciones y marcandola de la siguiente forma:

@ApplicationException(rollback = true)
public class MiException extends Exception

Al marcarla de esta forma le decimos al contenedor que este tipo de excepciones debe terminar con un rollback, es de suma importancion ponerle el parametro rollback=true, ya que este parametro por omision tiene un false y no hace rollback sino commit.

Espero les sirva este pequeño articulo resumido y no tenga que investigarlo tanto y les sea de ayuda.