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