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í) ¿Tengo que arrojar la excepción del método declarando la excepción en el método o bastará con arrojar una excepción dentro del método y manejarlo? está dentro del mismo método en sí? (No quiero propagar la excepción al siguiente nivel. Solo quiero deshacer la excepción.)

Gracias de antemano. ;)

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() obliga al contenedor a deshacer la transacción, también 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 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 un RuntimeException, la transacción se retrotraerá automáticamente. Si detecta 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 descargar gratis.

Answer 2

La cuestión de cómo evitar que las excepciones comprobadas anotadas declaradamente causen una reversión al lanzar desde la propagación 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 lanzarse contra el límite de método (y por lo tanto no atrapado & procesado dentro del método) Y propagarse para tener efecto transaccional, y también a su vez causará la destrucción de la instancia EJB.)