In Hibernate, we would e.g. avoid doing copying of entity
state for dirty checking, so we would just ask the
transaction whether it is read only, and if so, skip the
copying.
if ( !tx.isReadOnly() ) {
entityEntry.setLoadedState( deepCopy( state ) );
}
but I think it would be really nice if the datasources
implementation could also make use of this flag and switch
to a different JDBC connection pool i.e. one that connects
to a hot-standby for read-only transactions.
Am 08.12.2022 um 18:02 schrieb Tom Jenkinson:
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?
The `jakarta.transaction.Transaction` interface
would ideally expose the read-only information,
so that I can implement the optimizations in
Hibernate for this case.
Am 06.12.2022 um 11:59 schrieb Benedict
Eisenkrämer:
I think timeout and readOnly should be
more straight forward:
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 readonly.
For Isolation-Levels:
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:
As under the hood surely jdbc is used as
well, or am I wrong here?
On 06.12.22 10:45, Tom Jenkinson wrote:
Thank you for raising the topic!
I think an important consideration when
adding things to Jakarta Transactions is
what can the XAResource API support?
Rearding isolation levels, I don't
think we have a way to inform the
XAResource of isolation level and so
adding that something like that to Jakarta
Transactions it is not clear to me what an
implementation would do with that
information? Reading https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Isolation.html#DEFAULT
it seems intended to be specific to JDBC
and so it seems maybe Spring has a way to
merge a concept of datasource with their
Transactional annotation? I am not sure
the same would be appropriate for Jakarta
Transactions.
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
development.
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
:
Isolation levels
timeout
readOnly
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.