Ah, thank you - I think I see better now a usage for read-only beyond if it is useful for the compliant implementation to make it's own optimizations (if it wants to to) in that it could also be made available to the application server via something on Transaction in https://jakarta.ee/specifications/platform/10/apidocs/jakarta/transaction/transactionmanager. That said, I am not sure how an application server would reliably use this information by pulling it from a transaction object - to help me understand better, if you are able and happy to do so, please can you share some pseudo-code showing where this information could theoretically be used?
For readOnly the main benefit is in what the specific
implementaion makes of it (i.a. optimizations, as pointed out
by Christian). I think the only requirement should be, that no
entities may be updated, created or deleted. That way no work
should be enlisted and the transaction can be commited as
I do not 100% understand how the internals of the Transactional
Implementation(s) work, but from my naive standpoint shouldn't
it be possible to somehow acquire the currently used
java.sql.Connection and just do something like this:
I am new to this mailing list so maybe a few short
words to myself first: I am a Software Engineer in
Germany responsible for our JavaEE, soon to be JakartaEE
framework. I am quiet interested in JakartaEE and its
The topic I would like to discuss is the enhancement of
the @Transactional Annotation for JakartaEE 11. A good
template would be the Spring specific
Annotation of the same name which supports among
other things :
I already found a issue on github
regarding the Topic, which unfortunately has not seen
any attention given to it since 2016. So I wanted to
spark a discussion.
In my opinion these enhancement could be quiet helpful.