me too tha's why that's the last try ;) - Romain
2012/7/10 Stuart Douglas <[email protected]> > > 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 <[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 > >>>>> > >> > >>>>> > >> > >>>>> > > > >>>>> > > >>>>> > >>>> > >>> > >> > >
