You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by Mark Struberg <st...@yahoo.de> on 2012/07/09 20:46:16 UTC

DS-175 using EJB Transactions for CDI beans in a portable way

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 <ar...@openknowledge.de>
> To: "deltaspike-dev@incubator.apache.org" <de...@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 <st...@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 <ar...@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 <ar...@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 <st...@yahoo.de>
>>  >>
>>  >>  > +1 for JTA module.
>>  >>  >
>>  >>  > LieGrue,
>>  >>  > strub
>>  >>  >
>>  >>  >
>>  >>  >
>>  >>  > ----- Original Message -----
>>  >>  > > From: Arne Limburg 
> <ar...@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 <pm...@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
>>  >>  > >>
>>  >>  > >>
>>  >>  > >
>>  >>  >
>>  >>
>>  >
>> 
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@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 <sd...@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 <ar...@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 <st...@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 <ar...@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 
> <ar...@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 <st...@yahoo.de>
>>  >>>>>
>>  >>>>>   > +1 for JTA module.
>>  >>>>>   >
>>  >>>>>   > LieGrue,
>>  >>>>>   > strub
>>  >>>>>   >
>>  >>>>>   >
>>  >>>>>   >
>>  >>>>>   > ----- Original Message -----
>>  >>>>>   > > From: Arne Limburg
>>  >> <ar...@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 
> <pm...@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
>>  >>>>>   > >>
>>  >>>>>   > >>
>>  >>>>>   > >
>>  >>>>>   >
>>  >>>>>
>>  >>>>
>>  >>>
>>  >>
>> 
>> 
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
me too tha's why that's the last try ;)

- Romain


2012/7/10 Stuart Douglas <sd...@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 <ar...@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 <st...@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 <ar...@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 <ar...@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 <st...@yahoo.de>
> >>>>>
> >>>>>   > +1 for JTA module.
> >>>>>   >
> >>>>>   > LieGrue,
> >>>>>   > strub
> >>>>>   >
> >>>>>   >
> >>>>>   >
> >>>>>   > ----- Original Message -----
> >>>>>   > > From: Arne Limburg
> >> <ar...@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 <pm...@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
> >>>>>   > >>
> >>>>>   > >>
> >>>>>   > >
> >>>>>   >
> >>>>>
> >>>>
> >>>
> >>
>
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Stuart Douglas <sd...@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 <ar...@openknowledge.de>
>> To: "deltaspike-dev@incubator.apache.org" <de...@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 <st...@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 <ar...@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 <ar...@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 <st...@yahoo.de>
>>>>> 
>>>>>   > +1 for JTA module.
>>>>>   >
>>>>>   > LieGrue,
>>>>>   > strub
>>>>>   >
>>>>>   >
>>>>>   >
>>>>>   > ----- Original Message -----
>>>>>   > > From: Arne Limburg 
>> <ar...@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 <pm...@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
>>>>>   > >>
>>>>>   > >>
>>>>>   > >
>>>>>   >
>>>>> 
>>>> 
>>> 
>>

AW: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Arne Limburg <ar...@openknowledge.de>.
Yes, I have already coded some stuff.
I'll just commit it after the release of 0.3

Cheers,
Arne

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

as said earlier ut should often be fine so let's try this way ;)

- Romain


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

> OK, you mean the rollback case. We can try it, and if it does not
> work, we just have to rely on the container-behavior in the EjbTransactionHelper.
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Montag, 9. Juli 2012 21:53
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable
> way
>
> i mean you get an ejbcontext but you cnt use it because it is a bmt one.
>
> - Romain
>
>
> 2012/7/9 Arne Limburg <ar...@openknowledge.de>
>
> > Do you mean, we have no SessionContext in the JNDI in the CMT case,
> > why not? Don't mix this up with the UserTransaction!
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Montag, 9. Juli 2012 21:44
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: DS-175 using EJB Transactions for CDI beans in a
> > portable way
> >
> > yes but not the cmt case
> >
> > - Romain
> >
> >
> > 2012/7/9 Arne Limburg <ar...@openknowledge.de>
> >
> > > 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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > > > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > > > <st...@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 <st...@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 <rm...@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 <st...@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
> > > > > >> <ar...@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 <st...@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
> > > > > > <ar...@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
> > > > > > <ar...@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
> > > > > > <st...@yahoo.de>
> > > > > >>  >>>>  >>
> > > > > >>  >>>>  >>  > +1 for JTA module.
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  > LieGrue,
> > > > > >>  >>>>  >>  > strub
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > > > > >> Arne Limburg  >>> <ar...@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
> > > > > > <pm...@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
> > > > > >>  >>>>  >>  > >>
> > > > > >>  >>>>  >>  > >>
> > > > > >>  >>>>  >>  > >
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>
> > > > > >>  >>>>  >
> > > > > >>  >>>>
> > > > > >>  >>>
> > > > > >>  >>
> > > > > >>  >
> > > > > >>  >
> > > > > >>  >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
as said earlier ut should often be fine so let's try this way ;)

- Romain


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

> OK, you mean the rollback case. We can try it, and if it does not work, we
> just have to rely on the container-behavior in the EjbTransactionHelper.
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Montag, 9. Juli 2012 21:53
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable way
>
> i mean you get an ejbcontext but you cnt use it because it is a bmt one.
>
> - Romain
>
>
> 2012/7/9 Arne Limburg <ar...@openknowledge.de>
>
> > Do you mean, we have no SessionContext in the JNDI in the CMT case,
> > why not? Don't mix this up with the UserTransaction!
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Montag, 9. Juli 2012 21:44
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable
> > way
> >
> > yes but not the cmt case
> >
> > - Romain
> >
> >
> > 2012/7/9 Arne Limburg <ar...@openknowledge.de>
> >
> > > 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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > > > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > > > <st...@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 <st...@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 <rm...@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 <st...@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
> > > > > >> <ar...@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 <st...@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
> > > > > > <ar...@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
> > > > > > <ar...@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
> > > > > > <st...@yahoo.de>
> > > > > >>  >>>>  >>
> > > > > >>  >>>>  >>  > +1 for JTA module.
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  > LieGrue,
> > > > > >>  >>>>  >>  > strub
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > > > > >> Arne Limburg  >>> <ar...@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
> > > > > > <pm...@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
> > > > > >>  >>>>  >>  > >>
> > > > > >>  >>>>  >>  > >>
> > > > > >>  >>>>  >>  > >
> > > > > >>  >>>>  >>  >
> > > > > >>  >>>>  >>
> > > > > >>  >>>>  >
> > > > > >>  >>>>
> > > > > >>  >>>
> > > > > >>  >>
> > > > > >>  >
> > > > > >>  >
> > > > > >>  >
> > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>

AW: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Arne Limburg <ar...@openknowledge.de>.
OK, you mean the rollback case. We can try it, and if it does not work, we just have to rely on the container-behavior in the EjbTransactionHelper.

Cheers,
Arne

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

i mean you get an ejbcontext but you cnt use it because it is a bmt one.

- Romain


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

> Do you mean, we have no SessionContext in the JNDI in the CMT case,
> why not? Don't mix this up with the UserTransaction!
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Montag, 9. Juli 2012 21:44
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable
> way
>
> yes but not the cmt case
>
> - Romain
>
>
> 2012/7/9 Arne Limburg <ar...@openknowledge.de>
>
> > 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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > > <st...@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 <st...@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 <rm...@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 <st...@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
> > > > >> <ar...@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 <st...@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
> > > > > <ar...@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
> > > > > <ar...@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
> > > > > <st...@yahoo.de>
> > > > >>  >>>>  >>
> > > > >>  >>>>  >>  > +1 for JTA module.
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  > LieGrue,
> > > > >>  >>>>  >>  > strub
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > > > >> Arne Limburg  >>> <ar...@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
> > > > > <pm...@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
> > > > >>  >>>>  >>  > >>
> > > > >>  >>>>  >>  > >>
> > > > >>  >>>>  >>  > >
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>
> > > > >>  >>>>  >
> > > > >>  >>>>
> > > > >>  >>>
> > > > >>  >>
> > > > >>  >
> > > > >>  >
> > > > >>  >
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
i mean you get an ejbcontext but you cnt use it because it is a bmt one.

- Romain


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

> Do you mean, we have no SessionContext in the JNDI in the CMT case, why
> not? Don't mix this up with the UserTransaction!
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Montag, 9. Juli 2012 21:44
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: DS-175 using EJB Transactions for CDI beans in a portable way
>
> yes but not the cmt case
>
> - Romain
>
>
> 2012/7/9 Arne Limburg <ar...@openknowledge.de>
>
> > 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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > > <st...@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 <st...@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
> > > > >> <rm...@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 <st...@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
> > > > >> <ar...@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 <st...@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
> > > > > <ar...@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
> > > > > <ar...@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
> > > > > <st...@yahoo.de>
> > > > >>  >>>>  >>
> > > > >>  >>>>  >>  > +1 for JTA module.
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  > LieGrue,
> > > > >>  >>>>  >>  > strub
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > > > >> Arne Limburg  >>> <ar...@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
> > > > > <pm...@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
> > > > >>  >>>>  >>  > >>
> > > > >>  >>>>  >>  > >>
> > > > >>  >>>>  >>  > >
> > > > >>  >>>>  >>  >
> > > > >>  >>>>  >>
> > > > >>  >>>>  >
> > > > >>  >>>>
> > > > >>  >>>
> > > > >>  >>
> > > > >>  >
> > > > >>  >
> > > > >>  >
> > > > >>
> > > > >
> > > >
> > >
> >
>

AW: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Arne Limburg <ar...@openknowledge.de>.
Do you mean, we have no SessionContext in the JNDI in the CMT case, why not? Don't mix this up with the UserTransaction!

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

yes but not the cmt case

- Romain


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

> 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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > <st...@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 <st...@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
> > > >> <rm...@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 <st...@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
> > > >> <ar...@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 <st...@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
> > > > <ar...@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
> > > > <ar...@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
> > > > <st...@yahoo.de>
> > > >>  >>>>  >>
> > > >>  >>>>  >>  > +1 for JTA module.
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  > LieGrue,
> > > >>  >>>>  >>  > strub
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > > >> Arne Limburg  >>> <ar...@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
> > > > <pm...@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
> > > >>  >>>>  >>  > >>
> > > >>  >>>>  >>  > >>
> > > >>  >>>>  >>  > >
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>
> > > >>  >>>>  >
> > > >>  >>>>
> > > >>  >>>
> > > >>  >>
> > > >>  >
> > > >>  >
> > > >>  >
> > > >>
> > > >
> > >
> >
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes but not the cmt case

- Romain


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

> 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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > > <st...@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 <st...@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
> > > >> <rm...@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 <st...@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 <ar...@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 <st...@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
> > > > <ar...@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
> > > > <ar...@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
> > > > <st...@yahoo.de>
> > > >>  >>>>  >>
> > > >>  >>>>  >>  > +1 for JTA module.
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  > LieGrue,
> > > >>  >>>>  >>  > strub
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > > >> Arne Limburg  >>> <ar...@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
> > > > <pm...@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
> > > >>  >>>>  >>  > >>
> > > >>  >>>>  >>  > >>
> > > >>  >>>>  >>  > >
> > > >>  >>>>  >>  >
> > > >>  >>>>  >>
> > > >>  >>>>  >
> > > >>  >>>>
> > > >>  >>>
> > > >>  >>
> > > >>  >
> > > >>  >
> > > >>  >
> > > >>
> > > >
> > >
> >
>

AW: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Arne Limburg <ar...@openknowledge.de>.
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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > <st...@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 <st...@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
> > >> <rm...@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 <st...@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 <ar...@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 <st...@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
> > > <ar...@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
> > > <ar...@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
> > > <st...@yahoo.de>
> > >>  >>>>  >>
> > >>  >>>>  >>  > +1 for JTA module.
> > >>  >>>>  >>  >
> > >>  >>>>  >>  > LieGrue,
> > >>  >>>>  >>  > strub
> > >>  >>>>  >>  >
> > >>  >>>>  >>  >
> > >>  >>>>  >>  >
> > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From:
> > >> Arne Limburg  >>> <ar...@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
> > > <pm...@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
> > >>  >>>>  >>  > >>
> > >>  >>>>  >>  > >>
> > >>  >>>>  >>  > >
> > >>  >>>>  >>  >
> > >>  >>>>  >>
> > >>  >>>>  >
> > >>  >>>>
> > >>  >>>
> > >>  >>
> > >>  >
> > >>  >
> > >>  >
> > >>
> > >
> >
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ar...@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 <ar...@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 <rm...@gmail.com>
> > > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > > <st...@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 <st...@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 <rm...@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 <st...@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 <ar...@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 <st...@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
> > > <ar...@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
> > > <ar...@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
> > > <st...@yahoo.de>
> > >>  >>>>  >>
> > >>  >>>>  >>  > +1 for JTA module.
> > >>  >>>>  >>  >
> > >>  >>>>  >>  > LieGrue,
> > >>  >>>>  >>  > strub
> > >>  >>>>  >>  >
> > >>  >>>>  >>  >
> > >>  >>>>  >>  >
> > >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From: Arne
> > >> Limburg  >>> <ar...@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
> > > <pm...@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
> > >>  >>>>  >>  > >>
> > >>  >>>>  >>  > >>
> > >>  >>>>  >>  > >
> > >>  >>>>  >>  >
> > >>  >>>>  >>
> > >>  >>>>  >
> > >>  >>>>
> > >>  >>>
> > >>  >>
> > >>  >
> > >>  >
> > >>  >
> > >>
> > >
> >
>

AW: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Arne Limburg <ar...@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 <ar...@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 <rm...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > <st...@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 <st...@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 <rm...@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 <st...@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 <ar...@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 <st...@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
> > <ar...@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
> > <ar...@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
> > <st...@yahoo.de>
> >>  >>>>  >>
> >>  >>>>  >>  > +1 for JTA module.
> >>  >>>>  >>  >
> >>  >>>>  >>  > LieGrue,
> >>  >>>>  >>  > strub
> >>  >>>>  >>  >
> >>  >>>>  >>  >
> >>  >>>>  >>  >
> >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From: Arne
> >> Limburg  >>> <ar...@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
> > <pm...@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
> >>  >>>>  >>  > >>
> >>  >>>>  >>  > >>
> >>  >>>>  >>  > >
> >>  >>>>  >>  >
> >>  >>>>  >>
> >>  >>>>  >
> >>  >>>>
> >>  >>>
> >>  >>
> >>  >
> >>  >
> >>  >
> >>
> >
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ar...@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 <rm...@gmail.com>
> > To: deltaspike-dev@incubator.apache.org; Mark Struberg
> > <st...@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 <st...@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 <rm...@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 <st...@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 <ar...@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 <st...@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
> > <ar...@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
> > <ar...@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
> > <st...@yahoo.de>
> >>  >>>>  >>
> >>  >>>>  >>  > +1 for JTA module.
> >>  >>>>  >>  >
> >>  >>>>  >>  > LieGrue,
> >>  >>>>  >>  > strub
> >>  >>>>  >>  >
> >>  >>>>  >>  >
> >>  >>>>  >>  >
> >>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From: Arne
> >> Limburg  >>> <ar...@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
> > <pm...@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
> >>  >>>>  >>  > >>
> >>  >>>>  >>  > >>
> >>  >>>>  >>  > >
> >>  >>>>  >>  >
> >>  >>>>  >>
> >>  >>>>  >
> >>  >>>>
> >>  >>>
> >>  >>
> >>  >
> >>  >
> >>  >
> >>
> >
>

AW: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Arne Limburg <ar...@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 <rm...@gmail.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg 
> <st...@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 <st...@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 <rm...@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 <st...@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 <ar...@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 <st...@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
> <ar...@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
> <ar...@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
> <st...@yahoo.de>
>>  >>>>  >>
>>  >>>>  >>  > +1 for JTA module.
>>  >>>>  >>  >
>>  >>>>  >>  > LieGrue,
>>  >>>>  >>  > strub
>>  >>>>  >>  >
>>  >>>>  >>  >
>>  >>>>  >>  >
>>  >>>>  >>  > ----- Original Message -----  >>>>  >>  > > From: Arne 
>> Limburg  >>> <ar...@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
> <pm...@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
>>  >>>>  >>  > >>
>>  >>>>  >>  > >>
>>  >>>>  >>  > >
>>  >>>>  >>  >
>>  >>>>  >>
>>  >>>>  >
>>  >>>>
>>  >>>
>>  >>
>>  >
>>  >
>>  >
>> 
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Mark Struberg <st...@yahoo.de>.
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 <rm...@gmail.com>
> To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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 <st...@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 <rm...@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 <st...@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 <ar...@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 <st...@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 
> <ar...@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 
> <ar...@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 
> <st...@yahoo.de>
>>  >>>>  >>
>>  >>>>  >>  > +1 for JTA module.
>>  >>>>  >>  >
>>  >>>>  >>  > LieGrue,
>>  >>>>  >>  > strub
>>  >>>>  >>  >
>>  >>>>  >>  >
>>  >>>>  >>  >
>>  >>>>  >>  > ----- Original Message -----
>>  >>>>  >>  > > From: Arne Limburg
>>  >>> <ar...@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 
> <pm...@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
>>  >>>>  >>  > >>
>>  >>>>  >>  > >>
>>  >>>>  >>  > >
>>  >>>>  >>  >
>>  >>>>  >>
>>  >>>>  >
>>  >>>>
>>  >>>
>>  >>
>>  >
>>  >
>>  >
>> 
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
this way you'll not control the Tx

- Romain


2012/7/9 Mark Struberg <st...@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 <rm...@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 <st...@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 <ar...@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 <st...@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 <ar...@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 <ar...@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 <st...@yahoo.de>
> >>>>  >>
> >>>>  >>  > +1 for JTA module.
> >>>>  >>  >
> >>>>  >>  > LieGrue,
> >>>>  >>  > strub
> >>>>  >>  >
> >>>>  >>  >
> >>>>  >>  >
> >>>>  >>  > ----- Original Message -----
> >>>>  >>  > > From: Arne Limburg
> >>> <ar...@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 <pm...@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
> >>>>  >>  > >>
> >>>>  >>  > >>
> >>>>  >>  > >
> >>>>  >>  >
> >>>>  >>
> >>>>  >
> >>>>
> >>>
> >>
> >
> >
> >
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Mark Struberg <st...@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 <rm...@gmail.com>
>To: deltaspike-dev@incubator.apache.org; Mark Struberg <st...@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 <st...@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 <ar...@openknowledge.de>
>>> To: "deltaspike-dev@incubator.apache.org" <de...@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 <st...@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 <ar...@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 <ar...@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 <st...@yahoo.de>
>>>>  >>
>>>>  >>  > +1 for JTA module.
>>>>  >>  >
>>>>  >>  > LieGrue,
>>>>  >>  > strub
>>>>  >>  >
>>>>  >>  >
>>>>  >>  >
>>>>  >>  > ----- Original Message -----
>>>>  >>  > > From: Arne Limburg
>>> <ar...@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 <pm...@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
>>>>  >>  > >>
>>>>  >>  > >>
>>>>  >>  > >
>>>>  >>  >
>>>>  >>
>>>>  >
>>>>
>>>
>>
>
>
>

Re: DS-175 using EJB Transactions for CDI beans in a portable way

Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <st...@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 <ar...@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 <st...@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 <ar...@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 <ar...@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 <st...@yahoo.de>
> >>  >>
> >>  >>  > +1 for JTA module.
> >>  >>  >
> >>  >>  > LieGrue,
> >>  >>  > strub
> >>  >>  >
> >>  >>  >
> >>  >>  >
> >>  >>  > ----- Original Message -----
> >>  >>  > > From: Arne Limburg
> > <ar...@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 <pm...@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
> >>  >>  > >>
> >>  >>  > >>
> >>  >>  > >
> >>  >>  >
> >>  >>
> >>  >
> >>
> >
>