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 <arne.limb...@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:rmannibu...@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 <strub...@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 <arne.limb...@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:rmannibu...@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 <arne.limb...@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:rmannibu...@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 <strub...@yahoo.de> >>>>> >>>>> > +1 for JTA module. >>>>> > >>>>> > LieGrue, >>>>> > strub >>>>> > >>>>> > >>>>> > >>>>> > ----- Original Message ----- >>>>> > > From: Arne Limburg >> <arne.limb...@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:rmannibu...@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 >>>>> > >> >>>>> > >> >>>>> > > >>>>> > >>>>> >>>> >>> >>