deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: DS-175 using EJB Transactions for CDI beans in a portable way
Date Tue, 10 Jul 2012 05:43:07 GMT
That's really only the last resort.
Regarding the Tx and Security I assume that we will add explicit declarations on that bean.



Regarding EjbContext and TCCL: Those are freak cases and  I agree with you that they are
utterly evil! But I actually do not care much. It's like invoking an EJB in the same location.
You will get those weird side effects with _every_ EJB. 

We just have to document that if you like to use CMT, then you might get all the possibly
crazy stuff from EJB as well.


The alternative would be to not support CMT at all and instead force a CDI-only system where
we explicitly disregard calls to EJBs (because of the crazy side effects you mentioned). Might
be saner at the end, but would not allow for an easy migration path.


LieGrue,
strub



----- Original Message -----
> From: Romain Manni-Bucau <rmannibucau@gmail.com>
> To: deltaspike-dev@incubator.apache.org
> Cc: 
> Sent: Tuesday, July 10, 2012 1:27 AM
> Subject: Re: DS-175 using EJB Transactions for CDI beans in a portable way
> 
> me too tha's why that's the last try ;)
> 
> - Romain
> 
> 
> 2012/7/10 Stuart Douglas <sdouglas@redhat.com>
> 
>> 
>>  Just something to be aware of is that invoking this EJB actually does a
>>  fair bit more than just start a transaction.
>> 
>>  - Available  java:comp and java:module entries may change, as it will be
>>  using the EjbTransactionHelper JNDI namespace
>>  - This EjbTransactionHelper may have interceptors applied to it by
>>  accident when using a wildcard mapping in ejb-jar.xml, which could give
>>  unexpected results
>>  - The EJB will perform exception wrapping, as per the rules in the EJB spec
>>  - Depending on the container this may change the TCCL to the TCCL of the
>>  deployment with the EJB (AS7 will do this if the EJB is in a different sub
>>  deployment)
>>  - The current EJBContext will be changed, so calls to EJBContext will have
>>  unexpected results
>>  - If no CDI request scope is available one will be created (seems unlikely)
>> 
>>  I think that this behaviour has the potential to confuse users.
>> 
>>  Stuart
>> 
>>  On 10/07/2012, at 4:46 AM, Mark Struberg wrote:
>> 
>>  > back to the original problem about how to integrate with container
>>  management.
>>  >
>>  > I found a solution which hopefully works for managing CDI beans with 
> EJB
>>  CMT - even in a 100% portable way.
>>  >
>>  > Please first take a look what I've done in TransactionHelper. The 
> same
>>  could basically be done _inside_ a CmtPersistenceStrategy.
>>  >
>>  > First we create an internal EJB:
>>  >
>>  >
>>  >> @Stateless // this is automatically transactional
>>  >
>>  >> public class EjbTransactionHelper
>>  >
>>  >>     public <T> T invokeTransactional(InvocationContext
>>  invocationContext) throws Exception
>>  >>     {
>>  >>         return invocationContext.proceed();
>>  >>     }
>>  >> }
>>  >
>>  >
>>  > and then we use this EJB inside the invoke method of the
>>  EePersistenceStrategy wrapping the target in a anynomous Callable which
>>  just invokes the 'real' target method.
>>  >
>>  >
>>  > private @Inject EjbTransactionHelper ejbTransaction;
>>  > ...
>>  > public Object execute(InvocationContext invocationContext) throws
>>  Exception
>>  > {
>>  > ...
>>  >
>>  >
>>  > and instead of directly invoking invocationContext.proceed() we just 
> use
>>  the EJB:
>>  >
>>  > ejbTransaction.invokeTransactional(invocationContext);
>>  >
>>  > Since the EJB will open the transaction for us, we are basically done 
> ...
>>  >
>>  >
>>  >
>>  > Wdyt?
>>  >
>>  > LieGrue,
>>  > strub
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > ----- Original Message -----
>>  >> From: Arne Limburg <arne.limburg@openknowledge.de>
>>  >> To: "deltaspike-dev@incubator.apache.org" <
>>  deltaspike-dev@incubator.apache.org>
>>  >> Cc:
>>  >> Sent: Monday, July 9, 2012 8:30 AM
>>  >> Subject: AW: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
>>  @Transactional
>>  >>
>>  >> For api it's fine,
>>  >> and then we have two impl modules, JPA and JTA?
>>  >>
>>  >> Cheers,
>>  >> Arne
>>  >>
>>  >> -----Ursprüngliche Nachricht-----
>>  >> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>>  >> Gesendet: Sonntag, 8. Juli 2012 21:37
>>  >> An: deltaspike-dev@incubator.apache.org; Mark Struberg
>>  >> Betreff: Re: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
>>  @Transactional
>>  >>
>>  >> sounds fine
>>  >>
>>  >> - Romain
>>  >>
>>  >>
>>  >> 2012/7/8 Mark Struberg <struberg@yahoo.de>
>>  >>
>>  >>> maybe we should just rename the jpa module to tx?
>>  >>>
>>  >>> There is no single import of any javax.persistence in
>>  >>> deltaspike-jpa-api yet.
>>  >>>
>>  >>> LieGrue,
>>  >>> strub
>>  >>>
>>  >>>
>>  >>>
>>  >>> ----- Original Message -----
>>  >>>> From: Arne Limburg <arne.limburg@openknowledge.de>
>>  >>>> To: "deltaspike-dev@incubator.apache.org" <
>>  >>> deltaspike-dev@incubator.apache.org>
>>  >>>> Cc:
>>  >>>> Sent: Sunday, July 8, 2012 8:39 PM
>>  >>>> Subject: AW: AW: [DISCUSS] [DELTASPIKE-175] 
> [DELTASPIKE-219]
>>  >>> @Transactional
>>  >>>>
>>  >>>> Yes, sounds good.
>>  >>>> The impl of that module could contain the JTA stuff. And 
> the JPA
>>  >>>> module
>>  >>> would
>>  >>>> contain the resource local stuff. Everybody that does not 
> need the
>>  >>>> JTA
>>  >>> then
>>  >>>> could just use the tx-api and the JPA api and impl.
>>  >>>>
>>  >>>> Cheers,
>>  >>>> Arne
>>  >>>>
>>  >>>> -----Ursprüngliche Nachricht-----
>>  >>>> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
>>  >>>> Gesendet: Sonntag, 8. Juli 2012 20:29
>>  >>>> An: deltaspike-dev@incubator.apache.org
>>  >>>> Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] 
> [DELTASPIKE-219]
>>  >>> @Transactional
>>  >>>>
>>  >>>> i thought the same, JTA shouldn't depend on JPA. 
> @Transactional
>>  >>>> should
>>  >>> be in
>>  >>>> a tx module then JPA could use it.
>>  >>>>
>>  >>>> wdyt?
>>  >>>>
>>  >>>> - Romain
>>  >>>>
>>  >>>>
>>  >>>> 2012/7/8 Arne Limburg 
> <arne.limburg@openknowledge.de>
>>  >>>>
>>  >>>>>   OK, but I am still not sure where to split it. While
>>  >> implementing
>>  >>>>> this, I got the feeling, that the @Transactional stuff 
> should
>>  >>>>> completely move out of the JPA module. It feeled quite 
> strange
>>  >> that
>>  >>>>> the JTA module depends on the JPA module...
>>  >>>>>
>>  >>>>>   I think, I'll push my stuff right after the 0.3 
> release and
>>  >> than
>>  >>>>> we  can discuss this at the code-base.
>>  >>>>>   Maybe I should put all into the JPA module and we 
> split it after
>>  >>
>>  >>>>> agreeing to a module structure?
>>  >>>>>
>>  >>>>>   Cheers,
>>  >>>>>   Arne
>>  >>>>>
>>  >>>>>   -----Ursprüngliche Nachricht-----
>>  >>>>>   Von: Romain Manni-Bucau 
> [mailto:rmannibucau@gmail.com]
>>  >>>>>   Gesendet: Sonntag, 8. Juli 2012 17:48
>>  >>>>>   An: deltaspike-dev@incubator.apache.org; Mark 
> Struberg
>>  >>>>>   Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] 
> [DELTASPIKE-219]
>>  >>>>> @Transactional
>>  >>>>>
>>  >>>>>   +1
>>  >>>>>
>>  >>>>>   - Romain
>>  >>>>>
>>  >>>>>
>>  >>>>>   2012/7/8 Mark Struberg <struberg@yahoo.de>
>>  >>>>>
>>  >>>>>   > +1 for JTA module.
>>  >>>>>   >
>>  >>>>>   > LieGrue,
>>  >>>>>   > strub
>>  >>>>>   >
>>  >>>>>   >
>>  >>>>>   >
>>  >>>>>   > ----- Original Message -----
>>  >>>>>   > > From: Arne Limburg
>>  >> <arne.limburg@openknowledge.de>  > > To:
>>  >>>>> "deltaspike-dev@incubator.apache.org" <  
>> 
>>  >>>>> deltaspike-dev@incubator.apache.org>
>>  >>>>>   > > Cc:
>>  >>>>>   > > Sent: Sunday, July 8, 2012 5:47 PM  > 
>>  Subject:
>>  >> AW: [DISCUSS]
>>  >>>>> [DELTASPIKE-175] [DELTASPIKE-219]  > > 
> @Transactional  >
>>  >>>   > > Hi,
>>  >>>>>>> I startet implementing it that way, but I 
> stumbled over
>>  >> another
>>  >>>> issue:
>>  >>>>>   > > We get a dependency to the JTA spec and 
> the EJB spec
>>  >> that way.
>>  >>>>> So
>>  >>>>
>>  >>>>>   > > our
>>  >>>>>   > JPA module
>>  >>>>>   > > only would work with this apis in the 
> classpath.
>>  >>>>>   > > Do we accept this or are we back on a JTA 
> module?
>>  >>>>>   > >
>>  >>>>>   > > Cheers,
>>  >>>>>   > > Arne
>>  >>>>>   > >
>>  >>>>>   > > -----Ursprüngliche Nachricht-----  > 
>>  Von:
>>  >> Romain Manni-Bucau
>>  >>>>> [mailto:rmannibucau@gmail.com]  > > Gesendet: 
> Donnerstag, 5.
>>  >> Juli
>>  >>>>> 2012 15:07  > > An: 
> deltaspike-dev@incubator.apache.org
>>  >>>>>   > > Betreff: Re: [DISCUSS] [DELTASPIKE-175]
>>  >> [DELTASPIKE-219]  > >
>>  >>>>> @Transactional  > >  > > if it works fine 
> with CMT +1
>>  >>>>   > >
>>  >>>>> well let's have a try, we'll fix it if it is 
> not enough
>>  >>>> ;)
>>  >>>>>   > >
>>  >>>>>   > > - Romain
>>  >>>>>   > >
>>  >>>>>   > >
>>  >>>>>   > > 2012/7/5 Pete Muir 
> <pmuir@redhat.com>  > >
>>  >>>>>   In Seam 2
>>  >>>>> we:
>>  >>>>>   > >>
>>  >>>>>   > >>  * checked if UT was available in 
> JNDI, and used it
>>  >> if it
>>  >>>> were
>>  >>>>>   > >>  * checked if there was a CMT 
> transaction, and used
>>  >> it (IIRC
>>  >>>> this
>>  >>>>>   > >> wwas  to work around abug)
>>  >>>>>   > >>  * otherwise tried to use a resource 
> local
>>  >> transaction (e.g.
>>  >>>> from
>>  >>>>>   > >>  Hibernate)
>>  >>>>>   > >>  * allowed the user to override and 
> specify one
>>  >> strategy  >
>>  >>>>>>>   > >>  In Seam 3 we did the same.
>>  >>>>>   > >>
>>  >>>>>   > >>  So I like option 1.
>>  >>>>>   > >>
>>  >>>>>   > >>  On 5 Jul 2012, at 10:03, Arne Limburg 
> wrote:
>>  >>>>>   > >>
>>  >>>>>   > >>  > Hi,
>>  >>>>>   > >>  >
>>  >>>>>   > >>  > yesterday I startet working on 
> the JTA
>>  >> support for
>>  >>>> @Transactional.
>>  >>>>>   > >>  > My current approach is to 
> implement a
>>  >>>> JtaPersistenceStrategy.
>>  >>>>>   > >>  > However that leads me to the 
> problem: Who
>>  >> decides which
>>  >>>>
>>  >>>>>   > >> PersistenceStrategy should be taken 
> and how should
>>  >> this
>>  >>>> decision
>>  >>>>>   > >> be
>>  >>>>>   > made?
>>  >>>>>   > >>  > I have three suggestions:
>>  >>>>>   > >>  >
>>  >>>>>   > >>  > 1.      We detect, if a 
> UserTransaction is
>>  >> available,
>>  >>>> if so, the
>>  >>>>>   > >>  JtaPersistenceStrategy is taken, 
> otherwise the
>>  >>>>>
>>  >>>>> ResourceLocalPersistenceStrategy is taken.
>>  >>>>>   > >>  >
>>  >>>>>   > >>  > 2.      We detect, if the 
> involved
>>  >> persistence units
>>  >>>> use JTA or
>>  >>>>>   > >>  RESOURCE_LOCAL (which would lead to 
> another
>>  >> question: Would
>>  >>>> we
>>  >>>>>   > >> like to  support, that @Transactional 
> mixes both
>>  >> strategies?)
>>  >>>> and
>>  >>>>>   > >> decide from  that information  >
>>  >>>>>   > >>  > 3.      We let the user decide 
> by making one
>>  >> (or both)
>>  >>>> persistence
>>  >>>>>   > >>  strategies @Alternatives
>>  >>>>>   > >>  > What do you think?
>>  >>>>>   > >>  >
>>  >>>>>   > >>  > Cheers,
>>  >>>>>   > >>  > Arne
>>  >>>>>   > >>
>>  >>>>>   > >>
>>  >>>>>   > >
>>  >>>>>   >
>>  >>>>>
>>  >>>>
>>  >>>
>>  >>
>> 
>> 
> 

Mime
View raw message