deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Limburg <arne.limb...@openknowledge.de>
Subject AW: DS-175 using EJB Transactions for CDI beans in a portable way
Date Mon, 09 Jul 2012 19:45:59 GMT
OK, but I just want to detect if we are in an EJB environment to use the EjbTransactionHelper...
And if someone puts an EJBContext into the JNDI, we can believe, we are within an EJBContainer
;-)

Cheers,
Arne

-----Ursprüngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
Gesendet: Montag, 9. Juli 2012 21:40
An: deltaspike-dev@incubator.apache.org
Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable way

can't we have an EJBContext facade which throw an exception for each method and no ut (is
the case i was thinking of)?

- Romain


2012/7/9 Arne Limburg <arne.limburg@openknowledge.de>

> OK,
> discard the "must be" ;-) But if we have @Transactional, an EJBContext
> and no UserTransaction, we can safely use the EjbTransactionHelper
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Montag, 9. Juli 2012 21:31
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable
> way
>
> hmm i dont like the 'it mush be" since it is not obvious.
>
> well maybe start with ut only then testing we'll see quickly what is
> missing
>
> - Romain
>
>
> 2012/7/9 Arne Limburg <arne.limburg@openknowledge.de>
>
> > Hi Mark,
> >
> > I had some other thoughts about it, that might work better, even in
> > nested
> > executions: We can use JNDI lookups to detect the scenario we are in:
> > 1. If a UserTransaction is available via java:comp/UserTransaction
> > use it 2. If a EJBContext is available via java:comp/EJBContext and
> > no UserTransaction is available, it must be the CMT case! Then we
> > could use your CMT EjbTransactionHelper and should use
> > EJBContext.setRollbackOnly to align behavior on Exceptions.
> > Else we should use the ResourceLocalPersistenceStrategy.
> >
> > Wdyt?
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Mark Struberg [mailto:struberg@yahoo.de]
> > Gesendet: Montag, 9. Juli 2012 21:02
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: DS-175 using EJB Transactions for CDI beans in a
> > portable way
> >
> > Dough, I do!
> >
> > As our EjbTransactionHelper is annotated @Stateless, it will have
> > CMT which closes the EM right after returning from the Server. All
> > subsequently called EJBs and CDI beans will use the EJB transaction.
> >
> > Of course, you cannot control rollback and commits but must rely on
> > the EJB container. But that's perfectly fine for some use cases.
> >
> > In practice we might have a JtaPersistenceStrategy which first does
> > an inspection of the intercepted class.
> >
> > 1. If the class contains an Extended EM -> use UserTransaction
> >
> >
> > 2. if the class contains a UserTransaction -> use UserTransaction
> >
> > 3.. else -> let EJB manage the transaction via the wrapper
> >
> >
> > LieGrue,
> > strub
> >
> >
> >
> > ----- Original Message -----
> > > From: Romain Manni-Bucau <rmannibucau@gmail.com>
> > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > <struberg@yahoo.de>
> > > Cc:
> > > Sent: Monday, July 9, 2012 8:54 PM
> > > Subject: Re: DS-175 using EJB Transactions for CDI beans in a
> > > portable way
> > >
> > >t his way you'll not control the Tx
> > >
> > > - Romain
> > >
> > >
> > > 2012/7/9 Mark Struberg <struberg@yahoo.de>
> > >
> > >>  Well this should be a candidate for a PersistenceStrategy of
> > >> @Transactional
> > >>
> > >>
> > >>  The question is how to pickup the right Strategy. This needs
> > >> some brainpower still...
> > >>
> > >>  LieGrue,
> > >>  strub
> > >>
> > >>  >________________________________  > From: Romain Manni-Bucau
> > >> <rmannibucau@gmail.com>
> > >>  >To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > <struberg@yahoo.de
> > >>  >
> > >>  >Sent: Monday, July 9, 2012 8:48 PM
> > >>  >Subject: Re: DS-175 using EJB Transactions for CDI beans in a
> > >> portable
> > > way
> > >>  >
> > >>  >
> > >>  >it is enough but where to put it?
> > >>  >
> > >>  >
> > >>  >what i like -> transparent and almost free  >what i don't
> > >> know-> what about JTA (which is more generic)?
> > >>  >what i don't like -> not compatible with @Transactional  >
> > >>  >- Romain
> > >>  >
> > >>  >
> > >>  >
> > >>  >2012/7/9 Mark Struberg <struberg@yahoo.de>  >  >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