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