The only reason why I potentially object is because we already have several scope annotations specified in CDI itself, when these annotations really do not belong there in the first place. There's no good reason I can think of why CDI should know what the "@RequestScope" or "@ConversationScope" is. AFAIK this was done as a convenience instead of doing work in the related specs, or as a separate deliverable of this spec. But I won't stand in the way. We already have precedent, it's already messy, and we can't fix it now ;) ~Lincoln From: "Reza Rahman" <reza_rahman(a)lycos.com&gt; To: cdi-dev(a)lists.jboss.org Sent: Tuesday, May 22, 2012 7:28:13 PM 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 _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

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

Cool – thanks for the kind words J.**** ** ** *From:* Fabien Marsaud [mailto:fabmars@gmail.com] *Sent:* Tuesday, May 22, 2012 8:30 PM *To:* Reza Rahman *Cc:* cdi-dev(a)lists.jboss.org *Subject:* Re: [cdi-dev] Transaction Scope for CDI**** ** ** My thought about the document is: Okay! It's logical, consistent, reasonable. I'll let you guys fight over the eventual location of @TrasnactionScoped Regards fm. **** On Wed, May 23, 2012 at 1:28 AM, Reza Rahman <reza_rahman(a)lycos.com&gt; wrote:**** 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**** -- http://www.suntriprecords.com**** _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

  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.

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  

Note that each managed bean method call begins and ends its own separate local context.

Note also that most Container-Managed Transactions

(CMT) span one or more manage bean method calls.  

________________________________ From: Reza Rahman <reza_rahman(a)lycos.com&gt; 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   

From: Reza Rahman <reza_rahman(a)lycos.com&gt; To: cdi-dev(a)lists.jboss.org Cc: Sent: Wednesday, May 23, 2012 8:18 PM Subject: Re: [cdi-dev] Transaction Scope for CDI Responses in-line... > -----Original Message----- > From: cdi-dev-bounces(a)lists.jboss.org [mailto:cdi-dev-bounces@lists.jboss.org] > On Behalf Of Mark Struberg > Sent: Wednesday, May 23, 2012 5:15 AM > To: cdi-dev(a)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).

From: Reza Rahman <reza_rahman(a)lycos.com&gt; To: cdi-dev(a)lists.jboss.org Cc: Sent: Wednesday, June 6, 2012 2:00 AM Subject: Re: [cdi-dev] Transaction Scope for CDI Sorry for the late reply to this, we have been trying to put some things together behind the scenes... It seems to me the primary issue here is the lack of use-cases driving the motivation for the proposal/focusing the discussion. Nigel did a great job of summarizing them here: http://java.net/projects/jms-spec/pages/JMSContextScopeUseCases. The use-cases for the JMS context I think presents a good super-set of how the transaction scope is likely used. As to use-cases beyond JTA vs. sticking to JTA, I think I'd prefer Pete weigh in on this. My standpoint remains that this should not be a focus for CDI since CDI is primarily a Java EE centric API and JTA is the standard transaction management API for Java EE. As to defining declarative transaction management annotations, that is being done in the JTA/Java EE spec (please check the recent archives for the Java EE EG). The annotations are clearly JTA centric. Regardless, the transaction scope can be defined completely separate of the higher level transaction management semantics as long as one sticks to JTA (which the current proposal does). As to the current wording of the proposal, I've asked Pete to take a look at this. As I've suggested, your points are unclear to me and I would certainly welcome a concrete alternate proposal. Hope this helps matters (particularly Nigel's use-cases). I would like to get a general idea on the possibility of including this scope in CDI 1.1. If this is not possible, the most prudent path for JMS would be to define this life-cycle as part of JMS 2 and leave the CDI EG be (much like the life-cycle of JPA being defined in a self-contained manner). In my opinion this would be a shame and a failure of due collaboration between the JMS and CDI EGs... > -----Original Message----- > From: Mark Struberg [mailto:struberg@yahoo.de] > Sent: Sunday, May 27, 2012 7:14 AM > To: Reza Rahman; cdi-dev(a)lists.jboss.org > Subject: Re: [cdi-dev] Transaction Scope for CDI > > > > Hi Reza, all! > > Sorry for the delay (pretty busy times right now). Response inline. > > LieGrue, > strub > > ----- Original Message ----- > > From: Reza Rahman <reza_rahman(a)lycos.com&gt; > > To: cdi-dev(a)lists.jboss.org > > Cc: > > Sent: Wednesday, May 23, 2012 8:18 PM > > Subject: Re: [cdi-dev] Transaction Scope for CDI > > > > Responses in-line... > > > >> -----Original Message----- > >> From: cdi-dev-bounces(a)lists.jboss.org > > [mailto:cdi-dev-bounces@lists.jboss.org] > >> On Behalf Of Mark Struberg > >> Sent: Wednesday, May 23, 2012 5:15 AM > >> To: cdi-dev(a)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? > > [strub] > EJB supports REQUIRES_NEW. Now for the wording it's something different > saying > > "If a contextual object is placed into the transaction context while a transaction > is active" > and > "A contextual instance is active AS LONG as the transaction is active" > But then again, you will just repeat the basic definition of a Context. It would be > much easier to just define the lifecycle boundaries of the TransactionContext. > See the wording of the CDI spec 6.7. "Context management for built-in scopes" > > > >> 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. > > [strub] > To me it seems that the proposed wording solely targets JTA use cases. And this > is imo way too narrow. > Imo we should start with summing up the supported use cases and the parts we > need for it: > > Needed 'parts' > * @Transactional annotation > * TransactionInterceptor implementation > * @TransactionScoped > anything else? > > Supported use cases: > * 1.) JTA Extended EM with UserTransaction > * 2.) JTA Container Managed EM in @Stateless EJBs > * 3.) JTA Container Managed EM in Message Driven Beans (do we need to > distinguish between 2. and 3. ?) > * 4.) CDI produced 'native'/'unmanaged' EntityManager > * 5.) Container managed EM injected in CDI beans > * 6.) Container managed EM injected in JSF managed beans > * various mixed scenarios of 2.) .. 4.) > anything else? > > Once we agree on those lists, THEN we can discuss about the implementation > details! > > Sidenote: in CODI (and DeltaSpike) we implemented this via 1 single Interceptor > implementation which injects a @Dependent PersistenceStrategy which the user > can switch via <alternatives>. Not sure though if we could specify it exactly that > way. > > >> 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... > > [strub] > > see my comment above regarding the wording in CDI spec 6.7. "Context > management for built-in scopes" > > > >> > >> 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. > > [strub] > See my note above 'set as active' vs 'active if' > > > >> > >> 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). > > [strub] > To be honest, JTA semantics are blurry to most users and often completely > container depending (when it comes to the gory details you need in big apps). > JTA is also really imposing heavy limitations to users, e.g. that you cannot > serialize open JTA transactions and there is also no portable way to propagate > JPA entity state across clusters when serialisation kicks in. Due to this restriction > a LOT projects either use DAOs in their JSF backing beans or do NOT use JTA at > all... > > >> 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. > > [strub] > It's really just s/contextual object/Contextual Instance/ > See 6.5, especially 6.5.2. "Contextual instance of a bean" > "Contextual Instance" is a well defined technical term in the CDI 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 > > > > [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? > > [strub] > We must take care to not implicitely introduce a cyclic reference which creates a > chicken-egg problem. E.g. a @TransactionScoped bean cannot open/control a > UserTransaction. > > > > > >> 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). > > [strub] > I see. This is targeted for 'auto transactions' which get created if a user is > executing a query _without_  calling em.getTransaction().begin()/commit(). > Please note that there is still a transaction in place - it's just not controlled by the > user. But the wording only fits the @Stateless EJB use case. All other use cases > outlined above would imo be broken with the very wording. > "Similarly, contextual objects can outlive method invocation boundaries if a > transaction spans multiple method calls." is especially very dangerous imo. How > would you implement this? I fear this behaviour would be nice for some use > cases and completely fuck up other ones. > > > > >> > 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. > > [strub] > But that doesn't work in practice. Usually only the outermost @Transactional > (implicite or explicite) method call will 'open' the transaction context. It might > get suspended when you call a method with > TransactionAttributeType.REQUIRES_NEW, but usually it just remains open. > > > >> > 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). > > [strub] > I've not written anything about @Stateful. The JSF managed bean spec defines > that @PersistenceContext might get injected. It doesn't say anything about > those restrictions. > PS: This is only true for container managed EntityManagers anyway... > PPS: The doc you mentioned only covers container managed EMs, thus leaving > out a wide share of productive projects which create and manage the EM > themselfs. E.g. almost all Spring based apps, and lots of others. I prefer to > reference the JSR specs instead (despite they are much harder to read than the > really good JBoss documents). > > > >> 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). > > [strub] > +1 for use cases. In CODI, TomEE, Seam-Persistence we already have a few > @Transactional implementations. > Please note that there are quite a few patterns out there which are _not_ > working on clusters! This is also because JPA has a few fundamental flaws which > I like to get fixed as well (see JPA_SPEC-21). > > I'm not sure if we can deliver a 1-fits-it-all logic. This might depend heavily on > how the user works within his application. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

From: Reza Rahman <reza_rahman(a)lycos.com&gt; To: Cc: &quot;cdi-dev(a)lists.jboss.org&quot; <cdi-dev(a)lists.jboss.org&gt; Sent: Thursday, June 7, 2012 5:56 AM Subject: Re: [cdi-dev] Transaction Scope for CDI Please note that this isn't an issue of taking anything personally. As a volunteer to the JCP I frankly have a limited amount of time to contribute to this and it really feels like things are getting nowhere with this and the discussion thus far has been barely technical, substantive or in the spirit of collaboration/cooperation. That being said, I am happy to discuss whatever needs to be clarified as long as the discussion is on-point, technically focused and specific. I have yet to understand what specifically you would like changed beyond that it seems you would like @Transaction defined in CDI, CDI to spec beyond JTA and this scope be defined in JTA all of which are problematic for reasons I already mentioned and would like the spec lead to weight-in on, and perhaps responsible folks from the Java EE EG (as opposed to continuing a repeating two way ping-pong on issues as much political as it is technical). As to the proposed text, I've repeatedly asked for specific suggestions as to what you would like changed and have even asked Pete to take a look. If you can be more helpful in these aspects, it would be great. On 6/6/2012 2:52 AM, Mark Struberg wrote: > Reza, this has nothing to do with us not like to collaborate. My point is that I don't like to have another fuzzy spec which ends up being completely non-portable between container vendors. And this is also not personally against you. You did a great job for a first attempt to get this down to paper. But we will definitely need a few more rounds here. > > I'll check the linked use-cases. > > Regarding JTA vs resource_local: all the EE is JTA. But as you can see with Spring, there is a nice way to interpret most of this stuff also for resource_local transaction management. We just need to take care about the wording a bit. > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Reza Rahman&lt;reza_rahman(a)lycos.com&gt; >> To: cdi-dev(a)lists.jboss.org >> Cc: >> Sent: Wednesday, June 6, 2012 2:00 AM >> Subject: Re: [cdi-dev] Transaction Scope for CDI >> >> Sorry for the late reply to this, we have been trying to put some things >> together behind the scenes... >> >> It seems to me the primary issue here is the lack of use-cases driving the >> motivation for the proposal/focusing the discussion. Nigel did a great job >> of summarizing them here: >> http://java.net/projects/jms-spec/pages/JMSContextScopeUseCases. The >> use-cases for the JMS context I think presents a good super-set of how the >> transaction scope is likely used. >> >> As to use-cases beyond JTA vs. sticking to JTA, I think I'd prefer Pete >> weigh in on this. My standpoint remains that this should not be a focus for >> CDI since CDI is primarily a Java EE centric API and JTA is the standard >> transaction management API for Java EE. As to defining declarative >> transaction management annotations, that is being done in the JTA/Java EE >> spec (please check the recent archives for the Java EE EG). The annotations >> are clearly JTA centric. Regardless, the transaction scope can be defined >> completely separate of the higher level transaction management semantics as >> long as one sticks to JTA (which the current proposal does). >> >> As to the current wording of the proposal, I've asked Pete to take a look at >> this. As I've suggested, your points are unclear to me and I would certainly >> welcome a concrete alternate proposal. >> >> Hope this helps matters (particularly Nigel's use-cases). >> >> I would like to get a general idea on the possibility of including this >> scope in CDI 1.1. If this is not possible, the most prudent path for JMS >> would be to define this life-cycle as part of JMS 2 and leave the CDI EG be >> (much like the life-cycle of JPA being defined in a self-contained manner). >> In my opinion this would be a shame and a failure of due collaboration >> between the JMS and CDI EGs... >> >>>   -----Original Message----- >>>   From: Mark Struberg [mailto:struberg@yahoo.de] >>>   Sent: Sunday, May 27, 2012 7:14 AM >>>   To: Reza Rahman; cdi-dev(a)lists.jboss.org >>>   Subject: Re: [cdi-dev] Transaction Scope for CDI >>> >>> >>> >>>   Hi Reza, all! >>> >>>   Sorry for the delay (pretty busy times right now). Response inline. >>> >>>   LieGrue, >>>   strub >>> >>>   ----- Original Message ----- >>>   >  From: Reza Rahman&lt;reza_rahman(a)lycos.com&gt; >>>   >  To: cdi-dev(a)lists.jboss.org >>>   >  Cc: >>>   >  Sent: Wednesday, May 23, 2012 8:18 PM >>>   >  Subject: Re: [cdi-dev] Transaction Scope for CDI >>>   > >>>   >  Responses in-line... >>>   > >>>   >>  -----Original Message----- >>>   >>  From: cdi-dev-bounces(a)lists.jboss.org >>>   >  [mailto:cdi-dev-bounces@lists.jboss.org] >>>   >>  On Behalf Of Mark Struberg >>>   >>  Sent: Wednesday, May 23, 2012 5:15 AM >>>   >>  To: cdi-dev(a)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? >>> >>>   [strub] >>>   EJB supports REQUIRES_NEW. Now for the wording it's something different >>>   saying >>> >>>   "If a contextual object is placed into the transaction context while a >> transaction >>>   is active" >>>   and >>>   "A contextual instance is active AS LONG as the transaction is >> active" >>>   But then again, you will just repeat the basic definition of a Context. It >> would be >>>   much easier to just define the lifecycle boundaries of the >> TransactionContext. >>>   See the wording of the CDI spec 6.7. "Context management for built-in >> scopes" >>> >>>   >>  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. >>> >>>   [strub] >>>   To me it seems that the proposed wording solely targets JTA use cases. And >> this >>>   is imo way too narrow. >>>   Imo we should start with summing up the supported use cases and the parts >> we >>>   need for it: >>> >>>   Needed 'parts' >>>   * @Transactional annotation >>>   * TransactionInterceptor implementation >>>   * @TransactionScoped >>>   anything else? >>> >>>   Supported use cases: >>>   * 1.) JTA Extended EM with UserTransaction >>>   * 2.) JTA Container Managed EM in @Stateless EJBs >>>   * 3.) JTA Container Managed EM in Message Driven Beans (do we need to >>>   distinguish between 2. and 3. ?) >>>   * 4.) CDI produced 'native'/'unmanaged' EntityManager >>>   * 5.) Container managed EM injected in CDI beans >>>   * 6.) Container managed EM injected in JSF managed beans >>>   * various mixed scenarios of 2.) .. 4.) >>>   anything else? >>> >>>   Once we agree on those lists, THEN we can discuss about the implementation >>>   details! >>> >>>   Sidenote: in CODI (and DeltaSpike) we implemented this via 1 single >> Interceptor >>>   implementation which injects a @Dependent PersistenceStrategy which the >> user >>>   can switch via<alternatives>. Not sure though if we could specify it >> exactly that >>>   way. >>> >>>   >>  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... >>> >>>   [strub] >>> >>>   see my comment above regarding the wording in CDI spec 6.7. "Context >>>   management for built-in scopes" >>> >>> >>>   >> >>>   >>  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. >>> >>>   [strub] >>>   See my note above 'set as active' vs 'active if' >>> >>> >>>   >> >>>   >>  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). >>> >>>   [strub] >>>   To be honest, JTA semantics are blurry to most users and often completely >>>   container depending (when it comes to the gory details you need in big >> apps). >>>   JTA is also really imposing heavy limitations to users, e.g. that you >> cannot >>>   serialize open JTA transactions and there is also no portable way to >> propagate >>>   JPA entity state across clusters when serialisation kicks in. Due to this >> restriction >>>   a LOT projects either use DAOs in their JSF backing beans or do NOT use >> JTA at >>>   all... >>> >>>   >>  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. >>> >>>   [strub] >>>   It's really just s/contextual object/Contextual Instance/ >>>   See 6.5, especially 6.5.2. "Contextual instance of a bean" >>>   "Contextual Instance" is a well defined technical term in the CDI >> 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 >>>   > >>>   >  [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? >>> >>>   [strub] >>>   We must take care to not implicitely introduce a cyclic reference which >> creates a >>>   chicken-egg problem. E.g. a @TransactionScoped bean cannot open/control a >>>   UserTransaction. >>> >>> >>>   > >>>   >>  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). >>> >>>   [strub] >>>   I see. This is targeted for 'auto transactions' which get created >> if a >> user is >>>   executing a query _without_  calling em.getTransaction().begin()/commit(). >>>   Please note that there is still a transaction in place - it's just not >> controlled by the >>>   user. But the wording only fits the @Stateless EJB use case. All other use >> cases >>>   outlined above would imo be broken with the very wording. >>>   "Similarly, contextual objects can outlive method invocation >> boundaries if >> a >>>   transaction spans multiple method calls." is especially very dangerous >> imo. How >>>   would you implement this? I fear this behaviour would be nice for some use >>>   cases and completely fuck up other ones. >>> >>> >>> >>>   >>  >  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. >>>   [strub] >>>   But that doesn't work in practice. Usually only the outermost >> @Transactional >>>   (implicite or explicite) method call will 'open' the transaction >> context. >> It might >>>   get suspended when you call a method with >>>   TransactionAttributeType.REQUIRES_NEW, but usually it just remains open. >>> >>> >>>   >>  >  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). >>> >>>   [strub] >>>   I've not written anything about @Stateful. The JSF managed bean spec >> defines >>>   that @PersistenceContext might get injected. It doesn't say anything >> about >>>   those restrictions. >>>   PS: This is only true for container managed EntityManagers anyway... >>>   PPS: The doc you mentioned only covers container managed EMs, thus leaving >>>   out a wide share of productive projects which create and manage the EM >>>   themselfs. E.g. almost all Spring based apps, and lots of others. I prefer >> to >>>   reference the JSR specs instead (despite they are much harder to read than >> the >>>   really good JBoss documents). >>> >>> >>>   >>  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). >>> >>>   [strub] >>>   +1 for use cases. In CODI, TomEE, Seam-Persistence we already have a few >>>   @Transactional implementations. >>>   Please note that there are quite a few patterns out there which are _not_ >>>   working on clusters! This is also because JPA has a few fundamental flaws >> which >>>   I like to get fixed as well (see JPA_SPEC-21). >>> >>>   I'm not sure if we can deliver a 1-fits-it-all logic. This might depend >> heavily on >>>   how the user works within his application. >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > ----- > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2012.0.2171 / Virus Database: 2433/5052 - Release Date: 06/06/12 > > > . > _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Sorry for the late reply to this, we have been trying to put some things together behind the scenes... It seems to me the primary issue here is the lack of use-cases driving the motivation for the proposal/focusing the discussion. Nigel did a great job of summarizing them here: http://java.net/projects/jms-spec/pages/JMSContextScopeUseCases. The use-cases for the JMS context I think presents a good super-set of how the transaction scope is likely used. As to use-cases beyond JTA vs. sticking to JTA, I think I'd prefer Pete weigh in on this. My standpoint remains that this should not be a focus for CDI since CDI is primarily a Java EE centric API and JTA is the standard transaction management API for Java EE.

As to defining declarative transaction management annotations, that is being done in the JTA/Java EE spec (please check the recent archives for the Java EE EG). The annotations are clearly JTA centric. Regardless, the transaction scope can be defined completely separate of the higher level transaction management semantics as long as one sticks to JTA (which the current proposal does).

As to the current wording of the proposal, I've asked Pete to take a look at this. As I've suggested, your points are unclear to me and I would certainly welcome a concrete alternate proposal. Hope this helps matters (particularly Nigel's use-cases). I would like to get a general idea on the possibility of including this scope in CDI 1.1.

If this is not possible, the most prudent path for JMS would be to define this life-cycle as part of JMS 2 and leave the CDI EG be (much like the life-cycle of JPA being defined in a self-contained manner). In my opinion this would be a shame and a failure of due collaboration between the JMS and CDI EGs... > -----Original Message----- > From: Mark Struberg [mailto:struberg@yahoo.de] > Sent: Sunday, May 27, 2012 7:14 AM > To: Reza Rahman; cdi-dev(a)lists.jboss.org > Subject: Re: [cdi-dev] Transaction Scope for CDI > > > > Hi Reza, all! > > Sorry for the delay (pretty busy times right now). Response inline. > > LieGrue, > strub > > ----- Original Message ----- >> From: Reza Rahman <reza_rahman(a)lycos.com&gt; >> To: cdi-dev(a)lists.jboss.org >> Cc: >> Sent: Wednesday, May 23, 2012 8:18 PM >> Subject: Re: [cdi-dev] Transaction Scope for CDI >> >> Responses in-line... >> >>> -----Original Message----- >>> From: cdi-dev-bounces(a)lists.jboss.org >> [mailto:cdi-dev-bounces@lists.jboss.org] >>> On Behalf Of Mark Struberg >>> Sent: Wednesday, May 23, 2012 5:15 AM >>> To: cdi-dev(a)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? > > [strub] > EJB supports REQUIRES_NEW. Now for the wording it's something different > saying > > "If a contextual object is placed into the transaction context while a transaction > is active" > and > "A contextual instance is active AS LONG as the transaction is active" > But then again, you will just repeat the basic definition of a Context. It would be > much easier to just define the lifecycle boundaries of the TransactionContext. > See the wording of the CDI spec 6.7. "Context management for built-in scopes" > > >>> 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. > > [strub] > To me it seems that the proposed wording solely targets JTA use cases. And this > is imo way too narrow. > Imo we should start with summing up the supported use cases and the parts we > need for it: > > Needed 'parts' > * @Transactional annotation > * TransactionInterceptor implementation > * @TransactionScoped > anything else? > > Supported use cases: > * 1.) JTA Extended EM with UserTransaction > * 2.) JTA Container Managed EM in @Stateless EJBs > * 3.) JTA Container Managed EM in Message Driven Beans (do we need to > distinguish between 2. and 3. ?) > * 4.) CDI produced 'native'/'unmanaged' EntityManager > * 5.) Container managed EM injected in CDI beans > * 6.) Container managed EM injected in JSF managed beans > * various mixed scenarios of 2.) .. 4.) > anything else? > > Once we agree on those lists, THEN we can discuss about the implementation > details! > > Sidenote: in CODI (and DeltaSpike) we implemented this via 1 single Interceptor > implementation which injects a @Dependent PersistenceStrategy which the user > can switch via <alternatives>. Not sure though if we could specify it exactly that > way. > >>> 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... > > [strub] > > see my comment above regarding the wording in CDI spec 6.7. "Context > management for built-in scopes" > > >>> >>> 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. > > [strub] > See my note above 'set as active' vs 'active if' > > >>> >>> 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). > > [strub] > To be honest, JTA semantics are blurry to most users and often completely > container depending (when it comes to the gory details you need in big apps). > JTA is also really imposing heavy limitations to users, e.g. that you cannot > serialize open JTA transactions and there is also no portable way to propagate > JPA entity state across clusters when serialisation kicks in. Due to this restriction > a LOT projects either use DAOs in their JSF backing beans or do NOT use JTA at > all... > >>> 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. > > [strub] > It's really just s/contextual object/Contextual Instance/ > See 6.5, especially 6.5.2. "Contextual instance of a bean" > "Contextual Instance" is a well defined technical term in the CDI 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 >> >> [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? > > [strub] > We must take care to not implicitely introduce a cyclic reference which creates a > chicken-egg problem. E.g. a @TransactionScoped bean cannot open/control a > UserTransaction. > > >> >>> 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). > > [strub] > I see. This is targeted for 'auto transactions' which get created if a user is > executing a query _without_ calling em.getTransaction().begin()/commit(). > Please note that there is still a transaction in place - it's just not controlled by the > user. But the wording only fits the @Stateless EJB use case. All other use cases > outlined above would imo be broken with the very wording. > "Similarly, contextual objects can outlive method invocation boundaries if a > transaction spans multiple method calls." is especially very dangerous imo. How > would you implement this? I fear this behaviour would be nice for some use > cases and completely fuck up other ones. > > > >>>> 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. > > [strub] > But that doesn't work in practice. Usually only the outermost @Transactional > (implicite or explicite) method call will 'open' the transaction context. It might > get suspended when you call a method with > TransactionAttributeType.REQUIRES_NEW, but usually it just remains open. > > >>>> 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). > > [strub] > I've not written anything about @Stateful. The JSF managed bean spec defines > that @PersistenceContext might get injected. It doesn't say anything about > those restrictions. > PS: This is only true for container managed EntityManagers anyway... > PPS: The doc you mentioned only covers container managed EMs, thus leaving > out a wide share of productive projects which create and manage the EM > themselfs. E.g. almost all Spring based apps, and lots of others. I prefer to > reference the JSR specs instead (despite they are much harder to read than the > really good JBoss documents). > > >>> 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). > > [strub] > +1 for use cases. In CODI, TomEE, Seam-Persistence we already have a few > @Transactional implementations. > Please note that there are quite a few patterns out there which are _not_ > working on clusters! This is also because JPA has a few fundamental flaws which > I like to get fixed as well (see JPA_SPEC-21). > > I'm not sure if we can deliver a 1-fits-it-all logic. This might depend heavily on > how the user works within his application. _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev