I have an @Stateless EJB method in which I
- delete some entries from a database
using JPAremove()‘s - throw an Exception that is annotated as
@ApplicationException(rollback=true)
I have no other transaction-specific annotations for the method (I set @TransactionAttribute(TransactionAttributeType.REQUIRED) but that should be the default anyway!). Transactions are container managed. JPA provider is EclipseLink.
And still, the transaction is not rolled back when the exception is thrown. Eg. the entries that I deleted from the database before the rollback don’t come back. Btw. I call entityManager.flush() before the throw, can it cause such behaviour (it shouldn’t)?
I also tried to call SessionContext.setRollbackOnly(), with the same result.
How can I debug this problem?
I’m using Glassfish v3 and Netbeans for debugging, but I’d be equally happy with println’s I just don’t know where to put them…
Just to clarify how do you get the EntityManager?
Indeed, this is the default and shouldn’t be required anyway.
Hmm, that’s very strange and unexpected.
No, flush != commit
Well, still unexpected (but at least consistent…).
Maybe activate the logging of the following categories (e.g. via the admin Console under Configuration > Logging > Log Levels) to see if you can spot anything weird:
As an alternative (sort of “poor man’s logging”), you could implement
SessionSynchronizationto get notified about transaction.Really weird problem…
See also
Chapter 7 Administering the Logging Service