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