[cdi-dev] Transaction Scope for CDI

[Reza Rahman]

Responses in-line...

> -----Original Message-----
> From: cdi-dev-bounces at lists.jboss.org
[mailto:cdi-dev-bounces at lists.jboss.org]
> On Behalf Of Mark Struberg
> Sent: Wednesday, May 23, 2012 5:15 AM
> To: cdi-dev at lists.jboss.org
> Subject: Re: [cdi-dev] Transaction Scope for CDI
> 
> 
> 
> 
> 
> Hi!
>  
> It's really hard to follow (and subsequently check the necessity) because
you
> didn't gave _reasons_ for all the behaviour.

[Reza Rahman] That's fair and something I anticipated. The problem is that
it would be a bit odd to discuss all the supporting use-cases in the spec
itself since the others do not. We can certainly do that here (to a great
degree Nigel, I and Pete already have) and maybe add to the spec if we deem
it necessary.

> 
> 
> 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.

[Reza Rahman] Can you kindly elaborate? As such, JTA does not allow nested
transactions. What it does allow is one or more suspended transactions in
the same call-stack. In case of CMT, this would be a non-issue since the
contextual objects would not be propagated beyond method invocation
boundaries. In case of BMT, you really can't suspend the transaction, so
this would work there as well?

> 
> 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. 

[Reza Rahman] Could you be more specific? That would be helpful in making
this more concrete.

>But I share Lincolns sentiments that
> CDI is NOT the right place to define this.

[Reza Rahman] If a significant portion of this EG feels this way, we can
certainly get this clarified by Bill, Linda, et al. My suspicion is that
although this might not be the ideal place, it is likely the most pragmatic
place. Either way, it would be good to vet out the technical aspects of the
proposal with CDI centric folks.

> 
> 
> 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.

[Reza Rahman] Hmm - not sure what you mean? Could you kindly propose
alternate text? If anything I felt I was writing too little...

> 
> 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?.

[Reza Rahman] I avoided calling out specific CMT cases to keep this compact.
The use-case is handled though if you trace it through. In the REQUIRES_NEW
case, if there is an existing transaction, it would be suspended and hence
any contextual instances that belong to it would not be propagated past the
new method invocation. If there wasn't an existing transaction, the case
would be relatively straight-forward -- the instance would be created and
placed into the transactional cache. In addition, it will propagated to the
end of the method call to handle the BMT/short-transaction use-case.

> 
> 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...

[Reza Rahman] It is true that this is deliberately focused on JTA. The basic
reason for this is ease of standardization since the JTA semantics are
known. If the JTA case can be standardized, I imagine one could tackle the
case of other transaction management APIs down the line if theirs APIs are
also adequately standardized as far as CDI/Java EE is concerned. Also,
personally I am a supporter of JTA and see few technical reasons to avoid
it's use. Nevertheless, I deliberately tried to keep that possibility open
(not the parenthetical remark about CMT/BMT==JTA).

> 
> Also please s/contextual object/Contextual Instance/ as this is a well
defined
> terminus tecnicus in the spec.

[Reza Rahman] Again, could you kindly propose specific alternate text? That
would be greatly helpful.

> 
> > 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

[Reza Rahman] Not sure I follow? The way it is specified, the object would
be created and propagated across the method call. Any transactions that
become active after the object is created can still be utilized by the
instance?

> 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.

[Reza Rahman] Right. This was the initial implementation/concept in Resin.
The trouble is that it is severely limiting for BMT and cases where there is
no active transaction. For example, the JPA entity manager can be used
outside of an active transaction as long as you stick to "read-only"
methods: . The case in the JMS context is even broader since you can use the
JMS APIs without a transaction (even within Java EE).

> 
> > Note that each managed bean method call begins and ends its own
> > separate local context.
> certainly not true for nested bean method calls...

[Reza Rahman] Not sure what you mean? Limiting propagation to method
boundaries was specifically designed to avoid sticky situations where
transactions may be suspended/activated on the same thread multiple times.

> 
> 
> > 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).

[Reza Rahman] Right, but the point is that CMT transactions can and do
indeed span multiple method calls (e.g. is transaction propagation is set to
REQUIRED or SUPPORTS). In such a case, the context would ensure that all
methods in a the call-stack participating in the transaction are referring
to the same instance.

> 
> 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.

[Reza Rahman] Yes, propagating instances across the transaction would handle
this the way it is described now. BTW, for JPA in particular, you are
actually not allowed to propagate EMS from stateful to stateless contexts:
http://docs.jboss.org/hibernate/entitymanager/3.5/reference/en/html/architec
ture.html (not a reasonable restriction IMO). 

> 
> 
> Of course those are only first 'feelings' and I certainly need more time
to get
> warm with the wording.

[Reza Rahman] Right -- I fully expect that and is the reason I will likely
need to tend to this discussion for a duration (which is fine). The issues
you raised are good conversation starters. Alternatively, we could start
with a bunch of use-cases and see how the proposal fits? Luckily, we do
already have those for the proposed JMS 2 context (maybe Nigel can oblige
here?). Also, I could pose some pseudo-code for the proposal (tends to be
easier to follow since it provides conditional structures which natural
language does not).

I do think this is an invaluable feature for starting to integrate
transactional/JCA aware resources in a meaningful way via CDI.

> 
> LieGrue,
> strub
> 
> 
> 
> >________________________________
> > From: Reza Rahman <reza_rahman at lycos.com>
> >To: cdi-dev at 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 at lists.jboss.org
> >https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> >
> >
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev