Hi Paul,
On (1), while I think its OK to choose to remove section 5, if we do this
it should have a new section (e.g. like the EJB 3.2 spec) that states
something like
Other Requirements
The behaviors described in the Javadoc specification of the JTA interfaces
are required functionality and must be implemented by compliant providers.
Otherwise I don't agree with removing this section.
(2) Thanks for that
(3) That conversation was focussed on @PostConstruct - I haven't seen the
equivalent discussion or specification of transaction behaviour for
@AroundTimeout. The EJB spec, for example, says the following:
"A timeout callback method on a bean with container-managed transactions
must have transaction attribute REQUIRED or REQUIRES_NEW (or Required or
RequiresNew if the deployment descriptor is used to specify the
transaction attribute). If the container-managed transaction is rolled
back, the container retries the timeout.
Note that the container must start a new transaction if the REQUIRED
(Required) transaction
attribute value is used. This transaction attribute value is allowed so
that specification of a transaction attribute for the timeout callback
method can be defaulted."
Which spec and section is transactional behaviour defined for
@AroundTimeout and other CDI managed bean lifecycle events?
Paul "Let me start a separate thread with CDI folks to resolve this."
Thanks - that is now CDI
https://issues.jboss.org/browse/CDI-355
(4) Paul "Understood, I will make this clarification. I believe this was
the rationale, ie not to restrict but to not have a requirement, ie leave
it "undefined" as you say."
Thanks - please can we get a draft that includes this update.
Ian "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. "
Paul "This feature is intended for use in CDI only. I'm not sure if that
answers your question. Please let me know what clarifications you would
suggest if you would."
Something like this.
The @Transaction annotation states:
"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."
Thats clear. What isn't is @TransactionScoped.
For @TransactionScoped I think we need something like:
"The javax.transaction.TransactionScoped annotation provides the ability
to
specify a standard CDI scope to define bean instances whose lifecycle is
scoped to the
currently active JTA transaction. This annotation cannot be used by
classes defined as managed beans by the Java EE specification, which have
non-contextual references."
I'm looking for some clarification along those lines.
(5) Paul: "I still need to make this update and also update the JDBC
version in one spot."
(6): Paul: "Yes, I will get this as well. I also have the (lifecycle)
interceptor topic(s) mentioned and a couple other minor items (like
removing "standard extension API" from JDBC and including interceptor spec
to the related documents), as well as any further feedback and mods of
course."
Thanks. Do we need to extend the PR window? I'd like to review a draft
with all the proposed changes in it before IBM signs off on the MDR.
Regards,
Ian
Ian Robinson, IBM Distinguished Engineer
WebSphere Foundation Chief Architect
IBM Hursley, UK
irobins_at_uk.ibm.com
Admin Assistant: Janet Brooks - jsbrooks12_at_uk.ibm.com
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>, Joseph Bergmark <bergmark_at_us.ibm.com>
Date: 15/03/2013 22:59
Subject: [jta-spec users] Re: latest rev of spec and
diff/comparison file
Hi Ian,
Thanks for the feedback. Replies inline...
On Mar 14, 2013, at 2:43 PM, Ian Robinson wrote:
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).
This was removed as it is redundant (and has been inconsistent for
versions now) with the actualy JTA API. This is also consistent with
many/most other specs which do not include the API in the spec.
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.
Yes, sorry, I neglected to post the latest diff when I posted the spec and
javadoc the other week:
http://java.net/projects/jta-spec/sources/spec-source-repository/content/jta1.1to1.2diff.pdf?rev=6
These are all version updates, removal of obsolete material, etc. and not
new functionality.
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.
I am referring to the interceptor types (AroundTimeout, AroundInvoke,
AroundConstruct). I just deferred tot he interceptor spec on this by
saying "Refer to the Interceptors
specification for more details." as you see in the snippet but I can add a
descriptive sentence if you have an idea.
This is actually the crux of the current "transactional interceptors and
lifecycle methods" thread(s) on this list (that you replied to) as well as
jsr342-experts_at_javaee-spec.java.net and so is an ongoing (but hopefully
concluding soon if not today) open issue. The email has the subject of
.
- 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.
Priority in general has been on the interceptor and CDI mailing lists and
the javadoc can be found here:
http://javaee-spec.java.net/nonav/javadocs/index.html?javax/interceptor/Interceptor.Priority.html
I sent out the/this question to this list on February 4:
"
Hello,
Please provide feedback on the assignment of a priority value for the
transaction interceptor(s that provides the functionality behind the new
Transactional annotation).
This is analogous to the "0" value in/of OTS ;) and the current proposal
is to use Interceptor.Priority.PLATFORM_BEFORE+200 (see below).
Again as we are running very short on time prompt feedback is greatly
appreciated.
Thanks,
Paul
"
I received one +1 from Redhat/JBoss.
- 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 don't recall exactly and couldn't find the reference, sorry ;-) . It
does read cleaner and server as a dynamic/catchall rather than a finite
listing of examples.
- 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?
Let me start a separate thread with CDI folks to resolve this.
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.
Understood, I will make this clarification. I believe this was the
rationale, ie not to restrict but to not have a requirement, ie leave it
"undefined" as you say.
- 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.
This feature is intended for use in CDI only. I'm not sure if that
answers your question. Please let me know what clarifications you would
suggest if you would.
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.
Yes, sorry, I still need to make this update and also update the JDBC
version in one spot.
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.
Yes, I will get this as well. I also have the (lifecycle) interceptor
topic(s) mentioned and a couple other minor items (like removing "standard
extension API" from JDBC and including interceptor spec to the related
documents), as well as any further feedback and mods of course.
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
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