Re: [jta-dev] JTA Transactional Interface - Reasoning Comment for Checke

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

Hi, Bernd,

I replied on the Quarkus issue https://github.com/quarkusio/quarkus/issues/34569 with more details, including how to create a custom @MyTransactional annotation with the default behavior to roll back on any transaction. I also mentioned there that it's already possible to change the default behavior by a CDI extension. These approaches are just not known by the majority of Java developers because Spring took over and nobody learns Jakarta EE in more detail beyond simple examples. Spring seems to have a specific config option or a class for almost every usecase, while Jakarta EE aims at having minimal API but endless possibilities of composing API components.

Where Jakarta EE is lacking is the documentation, more complex examples, and description of common usecases that can be addressed by a combination of Jakarta EE components. The newer parts of Jakarta EE, which are based on CDI, are brilliant in connecting different features and combining them together. Many common usecases are easily supported by a combination of Jakarta EE features, like in this case @Transactional combined with stereotype or CDI extension, but it's not always evident how to combine them. For experts in Jakarta EE it all makes sense because things just click, for newcomers it's not easy because these combinations are not documented and they often don't know about the possibilities until they study a lot more.

Can we add support in JTA to globally switch the default behavior of @Transactional? Definitely. 

Is it necessary? Not really, because there are already ways to do it pretty easily.

Is it easy to find out how to do it? Often not, and that's where Jakarta EE should improve. The specs like JTA could already describe some common usecases and provide examples. The official Jakarta Tutorial (https://jakarta.ee/learn) could cover these usecases. But, in the end, it's always about whether anybody has time to do it. If you and the Quarkus community could, for example, review the Jakarta Tutorial, and contribute improvements or at least raise issues to address, then we can greatly improve the situation together.

All the best,

Ondro Mihalyi

Director, Jakarta EE expert

OmniFish - Jakarta EE Consulting & Support | www.omnifish.ee

Omnifish OÜ, Narva mnt 5, 10117 Tallinn, Estonia | VAT: EE102487932

On Wed, Aug 20, 2025 at 2:24 PM Tom Jenkinson via jta-dev <jta-dev@xxxxxxxxxxx> wrote:

I welcome comments from the members of the Jakarta Transactions team that were involved in the addition of the Transactional annotation into the relevant version of the JavaEE JTA specification to provide some input on why this design approach was taken. Maybe it was a usability decision, but I
wasn't involved in that discussion.

I suppose it ends up as a trade-off between applications needing to manage a potentially list of exceptions to `dontRollbackOn` vs in the case any exception should rollback then adding `@Transactional(rollbackOn={Exception.class})`



On Tue, 2025-08-19 at 18:10 +0000, Bernd Huber via jta-dev wrote:
> 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:
>  * https://jakarta.ee/specifications/transactions/2.0/apidocs/jakarta/transaction/transactional
>
> 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:
>  * https://github.com/quarkusio/quarkus/issues/34569
>
> 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
>
>
>    Gesendet mit Proton Mail: ein sicherer E-Mail-Dienst.
> _______________________________________________
> jta-dev mailing list
> jta-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: Building C, IBM Hursley Office, Hursley Park Road, Winchester, Hampshire SO21 2JN
_______________________________________________
jta-dev mailing list
jta-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jta-dev