[cdi-dev] Transaction Scope for CDI

Mark Struberg struberg at yahoo.de
Wed May 23 05:15:08 EDT 2012





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



More information about the cdi-dev mailing list