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