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