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