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 <[email protected]>

> 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:[email protected]]
> Gesendet: Montag, 9. Juli 2012 21:31
> An: [email protected]
> 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 <[email protected]>
>
> > 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:[email protected]]
> > Gesendet: Montag, 9. Juli 2012 21:02
> > An: [email protected]
> > 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 <[email protected]>
> > > To: [email protected]; Mark Struberg
> > > <[email protected]>
> > > 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 <[email protected]>
> > >
> > >>  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 <[email protected]>
> > >>  >To: [email protected]; Mark Struberg
> > > <[email protected]
> > >>  >
> > >>  >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 <[email protected]>  >  >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 <[email protected]>  >>> To:
> > >> "[email protected]" <
> > >> [email protected]>
> > >>  >>> 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:[email protected]]  >>> Gesendet: Sonntag, 8. Juli 2012
> > >> 21:37  >>> An: [email protected]; Mark Struberg
> > >> >>> Betreff: Re: AW: AW: [DISCUSS] [DELTASPIKE-175]
> > > [DELTASPIKE-219]
> > >>  @Transactional
> > >>  >>>
> > >>  >>> sounds fine
> > >>  >>>
> > >>  >>> - Romain
> > >>  >>>
> > >>  >>>
> > >>  >>> 2012/7/8 Mark Struberg <[email protected]>  >>>  >>>>  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
> > > <[email protected]>
> > >>  >>>>  > To: "[email protected]"
> > > <
> > >>  >>>>  [email protected]>
> > >>  >>>>  > 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:[email protected]]
> > >>  >>>>  > Gesendet: Sonntag, 8. Juli 2012 20:29  >>>>  > An:
> > >> [email protected]
> > >>  >>>>  > 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
> > > <[email protected]>
> > >>  >>>>  >
> > >>  >>>>  >>  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:[email protected]]
> > >>  >>>>  >>  Gesendet: Sonntag, 8. Juli 2012 17:48  >>>>  >>  An:
> > >> [email protected]; Mark
> > > Struberg
> > >>  >>>>  >>  Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175]
> > > [DELTASPIKE-219]
> > >>  >>>>  >> @Transactional
> > >>  >>>>  >>
> > >>  >>>>  >>  +1
> > >>  >>>>  >>
> > >>  >>>>  >>  - Romain
> > >>  >>>>  >>
> > >>  >>>>  >>
> > >>  >>>>  >>  2012/7/8 Mark Struberg
> > > <[email protected]>
> > >>  >>>>  >>
> > >>  >>>>  >>  > +1 for JTA module.
> > >>  >>>>  >>  >
> > >>  >>>>  >>  > LieGrue,
> > >>  >>>>  >>  > strub
> > >>  >>>>  >>  >
> > >>  >>>>  >>  >
> > >>  >>>>  >>  >
> > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From: Arne
> > >> Limburg  >>> <[email protected]>  > > To:
> > >>  >>>>  >> "[email protected]"
> > > <  >
> > >>  >>>>  >> [email protected]>
> > >>  >>>>  >>  > > 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:[email protected]]  > >
> > > Gesendet: Donnerstag, 5.
> > >>  >>> Juli
> > >>  >>>>  >> 2012 15:07  > > An:
> > > [email protected]
> > >>  >>>>  >>  > > 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
> > > <[email protected]>  > >
> > >>  >>>>  >>  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
> > >>  >>>>  >>  > >>
> > >>  >>>>  >>  > >>
> > >>  >>>>  >>  > >
> > >>  >>>>  >>  >
> > >>  >>>>  >>
> > >>  >>>>  >
> > >>  >>>>
> > >>  >>>
> > >>  >>
> > >>  >
> > >>  >
> > >>  >
> > >>
> > >
> >
>

Reply via email to