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