[cdi-dev] Transaction Scope for CDI
Mark Struberg
struberg at yahoo.de
Mon Jun 11 03:08:21 EDT 2012
I have a big conference to prepare for and can start working on it in July.
LieGrue,
strub
----- Original Message -----
> From: Reza Rahman <reza_rahman at lycos.com>
> To:
> Cc: "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org>
> 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<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