-
Bug
-
Resolution: Done
-
Major
-
5.11.0.Final
-
None
Currently when a @Transactional method throws an java.lang.Error the transaction is not rolled-back.
But, the java.lang.Error is an un-checked exception and such behaviour is wrong and the transaction should be rolled-back.
The JTA spec does not define the behaviour precisely for @Transactional. But from other spec or other parts of JTA spec we can consider the Error should rollback the transaction.
The JTA spec says about exceptions for @Transactional annotation:
By default checked exceptions do not result in the transactional interceptor marking
the transaction for rollback and instances of RuntimeException and its subclasses do.
But from information about Synchronization at JTA spec
An unchecked exception thrown by a registered Synchronization object
causes the transaction to be aborted.
or about transaction handling withing EJB spec
all other exceptions [meant non-application-exceptions]
should "Mark the transaction for rollback."
- causes
-
WFLY-14663 Nested transaction committed on [OutOfMemory]Error
- Closed