Hi!
It's really hard to follow (and subsequently check the necessity) because you
didn't gave _reasons_ for all the behaviour.
E.g.
If a contextual object is placed into the transaction context while
a transaction is active, the object will remain available until the
transaction is committed or rolled-back.
What about nested transactions? That would then Clash with the NormalScoped definition.
Imo the wording is way too abstract. I know this is really hard stuff to get right and
I'd like to thank you for picking this up. But I share Lincolns sentiments that CDI is
NOT the right place to define this.
You can definitely spare the whole paragraph above (not only the quoted parts, but the
whole one), because this is automatically defined if you describe the lifecycle of the
@TransactionScoped beans. Ie WHEN does the context start, WHEN does the context end and
WHEN is the context active/inactive inbetween.
Also your wording doesn't cover what happens if there is a method invocation with
TransactionAttributeType.REQUIRES_NEW ?
In this case the original @TransactionScoped should become isActive() ==false and a new
one should be opened, isn't?.
Also it's way too much fixated to JTA. There is a world outside of JTA :) Actually
most apps do NOT use JTA at all...
Also please s/contextual object/Contextual Instance/ as this is a well defined terminus
tecnicus in the spec.
Transactional contexts that come into effect in
complete absence of a transaction
are shared between all contextual objects in a single
managed bean method call
a.) you have a chicken egg problem if you e.g. try to @Produces @TransactionScoped
EntityManager and you do not yet have an open UserTransation
b.) imo if there is no open Transaction HANDLER then the Context#isActive() shall return
false, and accessing a Contextual Reference for a @TransactionScoped bean will lead to a
ContextNotActiveException.
Note that each managed bean method call begins
and ends its own separate local context.
certainly not true for nested bean method
calls...
Note also that most Container-Managed Transactions
(CMT) span one or more manage bean method calls.
I don't get that. Once your EJB method invocation returns, the built in
EJB-transaction-handler will commit that stuff and even close the involved EntityManager
(I'm talking about the REAL native EM and NOT the EntityManager facade you might see
as user).
Au contraire with an Extended EM, you might open the UserTransaction in a JSF backing bean
and keep it open during multiple @Stateless service invocations, finally closing the
UserTransaction before the JSF action returns.
Of course those are only first 'feelings' and I certainly need more time to get
warm with the wording.
LieGrue,
strub
________________________________
From: Reza Rahman <reza_rahman(a)lycos.com>
To: cdi-dev(a)lists.jboss.org
Sent: Wednesday, May 23, 2012 1:28 AM
Subject: [cdi-dev] Transaction Scope for CDI
CDI enthusiasts,
Pete, I and Nigel (JMS 2 spec lead) have been discussing the issue of the transaction
scope behind the scenes the past few weeks. Attached is what we came up with and feel it
meets the various related use-cases the most effectively. The downside is that it is quite
involved (conceptually) and might take a bit of patience to absorb. Please give it a read
and let me know your thoughts.
Cheers,
Reza
_______________________________________________
cdi-dev mailing list
cdi-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev