> We'd actually had a discussion around 2 and were thinking of using this
instead (hopefully the spec line itself explains the rationale):
Hi Paul, I'm a little confused - where did we have that discussion? The
last discussion I saw made sense whereas I don't think this does: allowing
access to UserTransaction with caveats that aren't enforced ("...the
application must ensure the UserTransaction is not used in a way that will
compromise the behavior of any transaction..."). JTA has been a solid spec
for a long time, including its integration with EJB, because we don't let
applications undermine the integrity of managed transactions. The good
news is that we already have the TransactionSynchronizationRegistry
interface for this kind of use and it should be fine to allow access to
that, as that interface is designed to offer no UOW control operations.
But UserTransaction should not be available to a method annotated with
@Transactional
Regards,
Ian
From: Paul Parkinson <paul.parkinson_at_oracle.com>
To: Ian Robinson/UK/IBM_at_IBMGB,
Cc: users_at_jta-spec.java.net, Linda DeMichiel
<linda.demichiel_at_oracle.com>
Date: 25/02/2013 21:01
Subject: Re: [jta-spec users] latest rev of spec and
diff/comparison file
Thanks Ian. We'd actually had a discussion around 2 and were thinking of
using this instead (hopefully the spec line itself explains the
rationale):
"Use of the UserTransaction from within a method or bean annotated with
@Transactional is not restricted. For example, the UserTransaction may be
needed in these cases to mark the transaction for rollback or obtain the
status of a current transaction. However, the application must ensure the
UserTransaction is not used in a way that will compromise the behavior of
any transaction that may be managed by the container. In particular,
UserTransaction should not be used to commit or rollback a transaction
that was started by a transaction interceptor, as such an action might
compromise the integrity of the application."
Regards,
Paul
On Feb 25, 2013, at 3:55 PM, Ian Robinson wrote:
Thanks Paul - these look good for #2 and #3.
Regards,
Ian
From: Paul Parkinson <paul.parkinson_at_oracle.com>
To: Ian Robinson/UK/IBM_at_IBMGB,
Cc: users_at_jta-spec.java.net
Date: 25/02/2013 17:04
Subject: Re: [jta-spec users] latest rev of spec and
diff/comparison file
Hello Ian, replies on 2 and 3 inline...
On Feb 16, 2013, at 12:56 PM, Ian Robinson wrote:
Paul,
I have 3 concerns around the proposed new sections 3.7 and 3.8.
#1
My earlier comments/concerns about EJB/CDI behaviour remain and haven't
been resolved. This is detailed in the comments of the Jira feature:
http://java.net/jira/browse/JTA_SPEC-5
As suggested in the jira, I prefer something like:
In the spirit of not requiring the deployment process to detect and
prevent, could I suggest something like:
"When Transactional annotated managed beans are used in conjunction with
EJB container managed transactions the EJB container behavior is
unspecified and not portable. Valid container implementations include, but
are not limited to:
the bean may fail to deploy
the Transactional annotation may be ignored
the EJB container behavior is applied before the bean is called. When the
bean is called the CDI behavior is applied before calling the bean's
methods.
It is best practice to avoid such use of Transactional annotations in
conjunction with EJB container managed transactions in order to avoid
possible confusion. and lack of portability."
I listed some examples in the jira of why I believe we need this. The text
above allows the behaviour currently stated in the spec but also allows
alternative behaviours. This is an edge case that the spec recommends
avoiding but unless we provide flexibility along the these lines, we need
to go through the "awkward" cases I enumerated (and any others we can
think of - those were just a few that came to mind) and tighten up the
spec. I think we're better off with more flexible container behaviour.
#2
In your mail below you say
- perhaps explicitly mention that while UserTransaction should not be used
inside a Transactional CMT, unlike EJB, use will not actually be
restricted
I'd assumed the opposite so I agree we need to explicitly document
something. I think it needs to be an exception in the same way it is for
EJB CMT. If the container is managing the transaction then the management
is compromised by having the bean able to manipulate it.
I've added the following in 3.1:
" If an attempt to use the UserTransaction is made from within a bean or
method annotated with @Transactional an IllegalStateException must be
thrown."
#3
Section 3.8 says:
"The javax.transaction.cdi.TransactionScoped annotation provides the
ability to
specify a standard scope to define beans whose lifecycle are scoped to the
currently
active JTA transaction. The transaction scope is active when the return
from a call to
UserTransaction.getStatus or TransactionManager.getStatus is one ofthe
following
states:
Status.STATUS_ACTIVE
Status.STATUS_MARKED_ROLLBACK
Status.STATUS_PREPARED
Status.STATUS_UNKNOWN
Status.STATUS_PREPARING
Status.STATUS_COMMITTING
Status.STATUS_ROLLING_BACK
...
A javax.enterprise.context.ContextNotActiveException must be thrown if an
object
with this annotation is used when the transaction context is not
active.The object with
this annotation is associated with the JTA transaction where it is first
used and this
association is retained through any transaction suspend or resume calls as
well as
any beforeCompletion Synchronization calls until the transaction is
completed."
I interpret this as requiring a ContextNotActiveException to be thrown if
the TransactionScoped object is used while the transaction with which it
is associated is suspended from the thread on which the object is used. Is
that correct?
But then the psuedocode example says:
Transaction transaction = transactionManager.suspend(); //tx1 suspended
//assert testTxAssociationChangeBean still associated with tx1 and
// that no transaction scope is active.
How? Shouldn't I get ContextNotActiveException if I try to use
testTxAssociationChangeBean?
I meant this as an internal/implementation assertion but I do see that
this is confusing and it also makes it impossible to put actual portable
assertion code in the spec and so I've simply removed it. An assertion
for the ContextNotActiveException case already exists later in the
example.
Regards,
Ian
From: Paul Parkinson <paul.parkinson_at_oracle.com>
To: users_at_jta-spec.java.net,
Date: 04/02/2013 16:20
Subject: [jta-spec users] latest rev of spec and diff/comparison
file
Hello,
The latest rev of the spec can be found here:
http://java.net/projects/jta-spec/sources/spec-source-repository/content/jta-1_2-spec_v2.pdf?rev=4
along with the diff/comparison file here:
http://java.net/projects/jta-spec/sources/spec-source-repository/content/jta1.1-to-1.2comparison.pdf?rev=4
A few items I still need to address:
- fix/add links
- add CDI in "relationship to other java APIs" and reference sections
- perhaps explicitly mention that while UserTransaction should not be used
inside a Transactional CMT, unlike EJB, use will not actually be
restricted
- etc. ;)
As always feedback is greatly appreciated as we try to close this down for
final JTA 1.2.
Thanks,
Paul
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU