java - container - ejb transactions

Retroceso de transacción EJB3

Question

Estoy usando CMT en beans de sesión sin estado EJB3. También creé mi propia excepción con la anotación "@ApplicationException (rollback = true)".

1. ¿Tengo que usar "context.setRollbackOnly ()" cuando quiero deshacer la transacción?

2. ¿Puedo simplemente retrotraer la transacción arrojando una excepción dentro del método público en el bean?

3. Si es así (la respuesta a Q # 2 es sí), debo arrojar la excepción del método declarando la excepción en el método o será suficiente arrojar una excepción dentro del método y manejarlo dentro del mismo método ¿sí mismo? (No quiero propagar la excepción al siguiente nivel. Solo quiero deshacer la excepción).

Gracias por adelantado. ;)

Answer 1

En primer lugar, no hay reversión de una excepción, es una reversión de una transacción.

1. Si lanza su excepción con @ApplicationException(rollback=true) , no tiene que deshacer la transacción manualmente. Context.setRollbackOnly() fuerza al contenedor a deshacer la transacción, incluso si no hay una excepción.
2. Una excepción comprobada en sí misma no revierte una transacción. Necesita tener la anotación @ApplicationException(rollback=true) . Si la excepción es una RuntimeException y la excepción no se detecta, obliga al contenedor a deshacer la transacción. Pero cuidado, el contenedor descartará en este caso la instancia de EJB.
3. Como se menciona en 2.), si lanza una RuntimeException , la transacción se retrotraerá automáticamente. Si setRollbackOnly una excepción marcada dentro del código, debe usar setRollbackOnly para deshacer la transacción.

Para obtener más información, consulte el libro gratuito Mastering EJB . Describe muy bien los escenarios de retrotracción y se puede download .

Answer 2

La cuestión de cómo evitar que las excepciones comprobadas anotadas declaradamente causen una reversión en throwing para propagarse a la "capa superior" todavía no se responde aquí.

Creo que esto requerirá una envoltura alrededor del EJB en cuestión que se traga la excepción lanzada. (En otras palabras: creo que la excepción personalizada DEBE ser lanzada contra el límite del método (y por lo tanto no atrapada y procesada dentro del método) Y propagada para tener efecto transaccional, y también a su vez causará la destrucción de la instancia EJB.)