deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
Date Sun, 08 Jul 2012 15:47:56 GMT
+1

- Romain


2012/7/8 Mark Struberg <struberg@yahoo.de>

> +1 for JTA module.
>
> LieGrue,
> strub
>
>
>
> ----- Original Message -----
> > From: Arne Limburg <arne.limburg@openknowledge.de>
> > To: "deltaspike-dev@incubator.apache.org" <
> deltaspike-dev@incubator.apache.org>
> > 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:rmannibucau@gmail.com]
> > Gesendet: Donnerstag, 5. Juli 2012 15:07
> > An: deltaspike-dev@incubator.apache.org
> > 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 <pmuir@redhat.com>
> >
> >>  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
> >>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message