Thanks Paul.
I can now see the public review draft. Unfortunately it doesn't seem to
have the changes you said you were going to make. It also seems to have
several sections missing and a number of other changes that have not been
previously discussed on the JTA mailing list.
1) The draft is missing Section 5 (API Reference).
2) I see a new entry in Change History "Various update of stale material,
version updates, etc." that wasn't in the last version that was shared.
Please could we get a new document with change bars relative to JTA 1.1 to
see what these are.
3) There have been several changes in the text in sections 3.7 that have
not been discussed on the mailing list.
For example
Previous text in section 3.7
"The javax.transaction.cdi.Transactional annotation provides the
application the
ability to control transaction boundaries on CDI managed beans, as well as
classes defined as managed beans by the Java EE specification such as
servlets, JAX-RS resource classes, and JAX-WS service endpoints,
declaratively. This support is provided via an implementation of CDI
interceptors that conduct the necessary suspending, resuming, etc. A
javax.transaction.cdi.TransactionalException with a nested exception is
thrown from
the interceptor as appropriate. The TxType element of the annotation
indicates whether a bean method is to be executed within a transaction
context where the values provide the following corresponding behavior:"
New text in section 3.7:
"The javax.transaction.Transactional annotation provides the application
the ability to declaratively control transaction boundaries on CDI managed
beans, as
well as classes defined as managed beans by the Java EE specification, at
both the
class and method level. This support is provided via an implementation of
CDI
TRANSACTIONAL ANNOTATION 25
interceptors that conduct the necessary suspending, resuming, etc. The
Transactional interceptor interposes on business method invocation,
timeout
methods and lifecycle events. It does not interpose on constructor
invocations. The
Transactional interceptors must have a priority of
Interceptor.Priority.PLATFORM_BEFORE+200. Refer to the Interceptors
specification for more details.
The TxType element of the annotation indicates whether a bean method is to
be executed within a transaction context where the values provide the
following
corresponding behavior:"
- Please can you explain what is meant by "timeout methods and lifecycle
events" in this context? This is appearing for the first time in this
draft, which surprises me.
- Also, what is the significance and rationale behind
Interceptor.Priority.PLATFORM_BEFORE+200? I didn't see any discussion of
that on the mailing list either.
- The specific text around servlets etc has been removed but I think it is
still implied by "classes defined as managed beans" - can you clarify?
- I believe we need to additionally clarify a potential conflict between
JTA and CDI: servlets, JAX-RS resource classes, and JAX-WS service
endpoints are created by their containers with non-contextual references
(according to the platform specification EE 5.24 and in our
implementation) but the CDI spec (section 7.2) precludes bean with
non-contextual references from being intercepted:
7.2. Container invocations and interception
When the application invokes:
? a method of a bean via a contextual reference to the bean, as defined in
Section 6.5.3, ?Contextual reference for a
bean?, or
? a business method of a session bean via an EJB remote or local
reference,
the invocation is treated as a business method invocation.
--snip--
If, and only if, an invocation is a business method invocation:
? it passes through method interceptors and decorators, and
? in the case of a session bean, it is subject to EJB services such as
declarative transaction management, concurrency, se-
curity and asynchronicity, as defined by the EJB specification.
Otherwise, the invocation is treated as a normal Java method call and is
not intercepted by the container.
It seems like CDI 7.2 needs to extend the scope of "business method of a
session bean via an EJB remote or local reference" to include
@Transactional beans with non-contextual references. Can you confirm
whether this interpretation is correct and, if so, how the CDI spec could
be changed to be consistent?
4) There have been several changes in the text in sections 3.8 that have
not been discussed on the mailing list.
For example
- "The transaction context must be destroyed after completion call have
been made on enlisted resource but before any
Synchronization.afterCompletion methods are called."
This is new and hasn't been discussed on the mailing list before. Why
would the spec place a new contraint on implementation of transaction
context lifecycle in this section? Other parts of the specific describe
the context in afterCompletion as "undefined" (e.g.
registerInterposedSynchronization: The afterCompletion callback will be
invoked in an undefined context.). I disagree with introducing this
constraint as stated - its an implementation detail. I agree with the
intent which is to say that transactionScoped object should not be
available in afterCompletion. The previously shared draft of the spec
implied this without using this text.
- This section explicitly states that beans with this annotation have
contextual references, which excludes components whose lifecycle is
managed by a Java EE container (not CDI). What should be the result of
annotating such a component with @TransactionScoped? I think we need to
discuss what the behaviour is supposed to be and explicitly document it.
5) This draft still states Use of UserTransaction from within a method or
bean annotated with @Transactional is not restricted.
I had understood ("I'll update the spec and let you know... ") we were
going back to
" If an attempt to use the UserTransaction is made from within a bean or
method annotated with @Transactional an IllegalStateException must be
thrown."
with the use of TransactionSynchronizationRegistry being unrestricted.
6) We had agreed the following text would be reomved but it is still
present:
Transaction transaction = transactionManager.suspend(); //tx1 suspended
//assert testTxAssociationChangeBean still associated with tx1 and
// that no transaction scope is active.
Ian: How? Shouldn't I get ContextNotActiveException if I try to use
testTxAssociationChangeBean?
Paul: 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.
This code is still in the PR draft.
Regards,
Ian
From: Paul Parkinson <paul.parkinson_at_oracle.com>
To: users_at_jta-spec.java.net,
Cc: Linda DeMichiel <linda.demichiel_at_oracle.com>, Kevin Sutter
<sutter_at_us.ibm.com>
Date: 09/03/2013 18:39
Subject: [jta-spec users] Re: latest rev of spec and
diff/comparison file
Hi Ian,
Extremely sorry for that. I will post the spec and send an email to this
list now.
(I had originally thought the latest was at
http://jcp.org/aboutJava/communityprocess/maintenance/jsr907/index5.html)
Thanks,
Paul
On Mar 9, 2013, at 10:20 AM, Ian Robinson wrote:
Thanks Paul. On the mechanics of "I'll update the spec and let you
know...", I'm bothered that a MDR5 was started on Feb 28 without any
notice to this distribution (I only just found out that it started a week
before your attached mail) and the public review materials at
http://jcp.org/aboutJava/communityprocess/maintenance/jsr907/907ChangeLog.html
are just the 3 JIRAs - not the currently proposed concrete changes to the
specification. Am I looking in the wrong place? I'm not sure how to
proceed on an MDR that closes on April 1st without having seen a concrete
spec to vote on.
There is a further clarification I'd like around @Transactional but I'll
put that in a separate mail to this distribution.
Regards,
Ian
From: Paul Parkinson <paul.parkinson_at_oracle.com>
To: Ian Robinson/UK/IBM_at_IBMGB,
Cc: Linda DeMichiel <linda.demichiel_at_oracle.com>,
users_at_jta-spec.java.net
Date: 05/03/2013 19:59
Subject: Re: [jta-spec users] latest rev of spec and
diff/comparison file
Hi Ian,
Sorry, I just meant that Linda and I had a talk on it and likewise others
internally have since mentioned using/allowing
TransactionSynchronizationRegistry instead. Eg, I had sent this: "maybe
we disallow UserTransaction and allow TransactionSynchronizationRegistry
usage instead. TransactionSynchronizationRegistry does have
setRollbackOnly and getTransactionStatus but does not have
setTransactionTimeout."
So I think what you mention sounds like a good idea unless Linda or anyone
else sees an issue. I'll update the spec and let you know...
Thanks,
Paul
On Mar 5, 2013, at 2:13 PM, Ian Robinson wrote:
> 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
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