i'd like it but seems everybody doesn't like it

- Romain


2012/7/9 Arne Limburg <[email protected]>

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

Reply via email to