Should java.lang.Errors roll back transactions?

[jonasb]

Hello, I'm using transactions within the embeddable EJB3 container (RC9).

In some parts of my business logic I am using asserts to verify some state.
When an assert fails, an AssertionError is thrown, which is caught by the EJB's and converted in to a TransactionRolledBackException.

Is that really the correct behavior?
I thought transacted EJB's should catch runtime/remote exceptions (except for those annotated with ApplicationException(rollback=false)). And I also thought that the general idea with java.lang.Error is that the application shouldn't try to recover from one of those since they may lead to undeterministic behavior.

So, what I'm saying is, shouldn't the transacted EJB's catch Exceptions rather than Throwables?


Thnx / Jonas

[kconner]

The EJB3 forum is the correct place for this question, not here.

[marklittle]

I haven't looked at the EJB spec, but from a transaction service perspective (and specifically the OTS/JTS), the answer is clear: yes, it should cause the transaction to rollback. All errors and system-level exceptions must cause the transaction to abort to ensure consistency. In the case of the OTS, user-level exceptions are the "exception" to the rule and it's up to the application to decide whether or not it can recover without affecting the transaction.

[kconner]

This is a question for the EJB3 forum. and not here

The spec is clear on how these are handled. Any throwable which is not declared as an application exception (or marked with the appropriate annotation) causes the transaction to rollback.

Of course you can have an Error which does not rollback the transaction should you decide to do this. (not recommended)