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 >> > >> >> > >> >> > > >> > >> >
