Well this should be a candidate for a PersistenceStrategy of @Transactional
The question is how to pickup the right Strategy. This needs some brainpower still... LieGrue, strub >________________________________ > From: Romain Manni-Bucau <[email protected]> >To: [email protected]; Mark Struberg <[email protected]> >Sent: Monday, July 9, 2012 8:48 PM >Subject: Re: DS-175 using EJB Transactions for CDI beans in a portable way > > >it is enough but where to put it? > > >what i like -> transparent and almost free >what i don't know-> what about JTA (which is more generic)? >what i don't like -> not compatible with @Transactional > >- Romain > > > >2012/7/9 Mark Struberg <[email protected]> > >back to the original problem about how to integrate with container management. >> >>I found a solution which hopefully works for managing CDI beans with EJB CMT >>- even in a 100% portable way. >> >>Please first take a look what I've done in TransactionHelper. The same could >>basically be done _inside_ a CmtPersistenceStrategy. >> >>First we create an internal EJB: >> >> >>>@Stateless // this is automatically transactional >> >>>public class EjbTransactionHelper >> >>> public <T> T invokeTransactional(InvocationContext invocationContext) >>>throws Exception >>> { >>> return invocationContext.proceed(); >>> } >>>} >> >> >>and then we use this EJB inside the invoke method of the >>EePersistenceStrategy wrapping the target in a anynomous Callable which just >>invokes the 'real' target method. >> >> >>private @Inject EjbTransactionHelper ejbTransaction; >>... >>public Object execute(InvocationContext invocationContext) throws Exception >>{ >>... >> >> >>and instead of directly invoking invocationContext.proceed() we just use the >>EJB: >> >>ejbTransaction.invokeTransactional(invocationContext); >> >>Since the EJB will open the transaction for us, we are basically done ... >> >> >> >>Wdyt? >> >>LieGrue, >>strub >> >> >> >> >> >>----- Original Message ----- >>> From: Arne Limburg <[email protected]> >>> To: "[email protected]" >>> <[email protected]> >>> Cc: >>> Sent: Monday, July 9, 2012 8:30 AM >>> Subject: AW: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] >>> @Transactional >>> >>> For api it's fine, >>> and then we have two impl modules, JPA and JTA? >>> >>> Cheers, >>> Arne >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Romain Manni-Bucau [mailto:[email protected]] >>> Gesendet: Sonntag, 8. Juli 2012 21:37 >>> An: [email protected]; Mark Struberg >>> Betreff: Re: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] >>> @Transactional >>> >>> sounds fine >>> >>> - Romain >>> >>> >>> 2012/7/8 Mark Struberg <[email protected]> >>> >>>> maybe we should just rename the jpa module to tx? >>>> >>>> There is no single import of any javax.persistence in >>>> deltaspike-jpa-api yet. >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> >>>> ----- Original Message ----- >>>> > From: Arne Limburg <[email protected]> >>>> > To: "[email protected]" < >>>> [email protected]> >>>> > Cc: >>>> > Sent: Sunday, July 8, 2012 8:39 PM >>>> > Subject: AW: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] >>>> @Transactional >>>> > >>>> > Yes, sounds good. >>>> > The impl of that module could contain the JTA stuff. And the JPA >>>> > module >>>> would >>>> > contain the resource local stuff. Everybody that does not need the >>>> > JTA >>>> then >>>> > could just use the tx-api and the JPA api and impl. >>>> > >>>> > Cheers, >>>> > Arne >>>> > >>>> > -----Ursprüngliche Nachricht----- >>>> > Von: Romain Manni-Bucau [mailto:[email protected]] >>>> > Gesendet: Sonntag, 8. Juli 2012 20:29 >>>> > An: [email protected] >>>> > Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] >>>> @Transactional >>>> > >>>> > i thought the same, JTA shouldn't depend on JPA. @Transactional >>>> > should >>>> be in >>>> > a tx module then JPA could use it. >>>> > >>>> > wdyt? >>>> > >>>> > - Romain >>>> > >>>> > >>>> > 2012/7/8 Arne Limburg <[email protected]> >>>> > >>>> >> OK, but I am still not sure where to split it. While >>> implementing >>>> >> this, I got the feeling, that the @Transactional stuff should >>>> >> completely move out of the JPA module. It feeled quite strange >>> that >>>> >> the JTA module depends on the JPA module... >>>> >> >>>> >> I think, I'll push my stuff right after the 0.3 release and >>> than >>>> >> we can discuss this at the code-base. >>>> >> Maybe I should put all into the JPA module and we split it after >>> >>>> >> agreeing to a module structure? >>>> >> >>>> >> Cheers, >>>> >> Arne >>>> >> >>>> >> -----Ursprüngliche Nachricht----- >>>> >> Von: Romain Manni-Bucau [mailto:[email protected]] >>>> >> Gesendet: Sonntag, 8. Juli 2012 17:48 >>>> >> An: [email protected]; Mark Struberg >>>> >> Betreff: Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] >>>> >> @Transactional >>>> >> >>>> >> +1 >>>> >> >>>> >> - Romain >>>> >> >>>> >> >>>> >> 2012/7/8 Mark Struberg <[email protected]> >>>> >> >>>> >> > +1 for JTA module. >>>> >> > >>>> >> > LieGrue, >>>> >> > strub >>>> >> > >>>> >> > >>>> >> > >>>> >> > ----- Original Message ----- >>>> >> > > From: Arne Limburg >>> <[email protected]> > > To: >>>> >> "[email protected]" < > >>>> >> [email protected]> >>>> >> > > Cc: >>>> >> > > Sent: Sunday, July 8, 2012 5:47 PM > > Subject: >>> AW: [DISCUSS] >>>> >> [DELTASPIKE-175] [DELTASPIKE-219] > > @Transactional > >>>> > > Hi, >>>> >> > > I startet implementing it that way, but I stumbled over >>> another >>>> > issue: >>>> >> > > We get a dependency to the JTA spec and the EJB spec >>> that way. >>>> >> So >>>> > >>>> >> > > our >>>> >> > JPA module >>>> >> > > only would work with this apis in the classpath. >>>> >> > > Do we accept this or are we back on a JTA module? >>>> >> > > >>>> >> > > Cheers, >>>> >> > > Arne >>>> >> > > >>>> >> > > -----Ursprüngliche Nachricht----- > > Von: >>> Romain Manni-Bucau >>>> >> [mailto:[email protected]] > > Gesendet: Donnerstag, 5. >>> Juli >>>> >> 2012 15:07 > > An: [email protected] >>>> >> > > Betreff: Re: [DISCUSS] [DELTASPIKE-175] >>> [DELTASPIKE-219] > > >>>> >> @Transactional > > > > if it works fine with CMT +1 >>>> > > > >>>> >> well let's have a try, we'll fix it if it is not enough >>>> > ;) >>>> >> > > >>>> >> > > - Romain >>>> >> > > >>>> >> > > >>>> >> > > 2012/7/5 Pete Muir <[email protected]> > > >>>> >> In Seam 2 >>>> >> we: >>>> >> > >> >>>> >> > >> * checked if UT was available in JNDI, and used it >>> if it >>>> > were >>>> >> > >> * checked if there was a CMT transaction, and used >>> it (IIRC >>>> > this >>>> >> > >> wwas to work around abug) >>>> >> > >> * otherwise tried to use a resource local >>> transaction (e.g. >>>> > from >>>> >> > >> Hibernate) >>>> >> > >> * allowed the user to override and specify one >>> strategy > >>>> >> >> > >> In Seam 3 we did the same. >>>> >> > >> >>>> >> > >> So I like option 1. >>>> >> > >> >>>> >> > >> On 5 Jul 2012, at 10:03, Arne Limburg wrote: >>>> >> > >> >>>> >> > >> > Hi, >>>> >> > >> > >>>> >> > >> > yesterday I startet working on the JTA >>> support for >>>> > @Transactional. >>>> >> > >> > My current approach is to implement a >>>> > JtaPersistenceStrategy. >>>> >> > >> > However that leads me to the problem: Who >>> decides which >>>> > >>>> >> > >> PersistenceStrategy should be taken and how should >>> this >>>> > decision >>>> >> > >> be >>>> >> > made? >>>> >> > >> > I have three suggestions: >>>> >> > >> > >>>> >> > >> > 1. We detect, if a UserTransaction is >>> available, >>>> > if so, the >>>> >> > >> JtaPersistenceStrategy is taken, otherwise the >>>> >> >>>> >> ResourceLocalPersistenceStrategy is taken. >>>> >> > >> > >>>> >> > >> > 2. We detect, if the involved >>> persistence units >>>> > use JTA or >>>> >> > >> RESOURCE_LOCAL (which would lead to another >>> question: Would >>>> > we >>>> >> > >> like to support, that @Transactional mixes both >>> strategies?) >>>> > and >>>> >> > >> decide from that information > >>>> >> > >> > 3. We let the user decide by making one >>> (or both) >>>> > persistence >>>> >> > >> strategies @Alternatives >>>> >> > >> > What do you think? >>>> >> > >> > >>>> >> > >> > Cheers, >>>> >> > >> > Arne >>>> >> > >> >>>> >> > >> >>>> >> > > >>>> >> > >>>> >> >>>> > >>>> >>> >> > > >
