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