[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[jta-dev] JTA Transactional Interface - Reasoning Comment for Checked Exception Handling
|
Hello everyone,
in a quarkus issue developers have discussed about the reasoning behind the JTA Transactional Interface "Checked Exception Handling", which is described in the Comment of the "Transactional" Interface class:
While the beviour itself is stated in the comment,
it would be great to also have a reasoning why "Checked Exceptions" are not leading to the Rollback of the Transactions.
Quote:
By default checked exceptions do not result in the transactional interceptor marking the
transaction for rollback and instances of RuntimeException and its subclasses do. This default
behavior can be modified by specifying exceptions that result in the interceptor marking the
transaction for rollback and/or exceptions that do not result in rollback.
It would be great if this comment could be enhanced with reasoning,
so developer teams can discuss about this behavior more clearly.
Such a discussion can be seen in the following "Quarkus" Issue:
The Developers there (even the quarkus team itself) does not seem to be able to explain why checked exceptions are not also leading to the rollback, and where the benefit for transaction safety is, and why the default case is not to always rollback for any kind of exceptions, and exclude specific ones when needed (whitelist)
best regards,
Bernd Huber
