[cdi-dev] Transaction Scope for CDI

Pete Muir pmuir at redhat.com
Tue Jun 12 09:09:21 EDT 2012

I hope to get to this soon Reza, apologies for the delay!

On 7 Jun 2012, at 04:56, Reza Rahman wrote:

> 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<reza_rahman at lycos.com>
>>> To: cdi-dev at 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 at yahoo.de]
>>>>  Sent: Sunday, May 27, 2012 7:14 AM
>>>>  To: Reza Rahman; cdi-dev at 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 at lycos.com>
>>>>> To: cdi-dev at 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 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?
>>>>  [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
>>>>> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev

More information about the cdi-dev mailing list