User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1
So you are referring to a scenario where a user marks a TX as
read-only, but some XAResource that is part of that TX doesn't
support this, right?
I think it's "ok" that the TX doesn't fail in such a scenario
when writes happen to such a XAResource. It's a limitation of the
XAResource, and if read-only semantics can't be implemented for
that resource, the implementer could emit a warning.
Am 08.12.2022 um 18:38 schrieb Tom
Jenkinson:
Thank you for the answers!
The transaction manager won't be able to detect the problem
in the resource managers so it could still be that some
resources are written to during a transaction that is marked
read-only, what do people think to the usability aspects of
that?
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.