[cdi-dev] Transaction Scope for CDI
Reza Rahman
reza_rahman at lycos.com
Wed Jun 6 23:56:22 EDT 2012
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
>
>
> .
>
More information about the cdi-dev
mailing list