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.