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: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
Date Thu, 05 Jul 2012 09:43:02 GMT
what about resource adapters?

- Romain


2012/7/5 Arne Limburg <arne.limburg@openknowledge.de>

> Ok, you are talking about javax.transaction.TransactionManager and
> javax.transaction.Transaction?
> The problem with this is, that the way to receive them is very
> container-dependent and we would have to maintain very much
> container-specific code.
> If we decide to go that way we definitely would need a separate JTA module.
> But the only benefit I see is that we could suspend and resume on
> transactions...
> Is that worth the effort?
> That would be something that a user could implement in a
> container-specific way, if he needs it...
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Donnerstag, 5. Juli 2012 11:31
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
>
> right but i wonder about the integration with a container managed
> transactions. UserTransaction is pretty close to resource local from a tx
> management point of view.
>
> - Romain
>
>
> 2012/7/5 Arne Limburg <arne.limburg@openknowledge.de>
>
> > That would come out of the box, when JTA UserTransaction is used or am
> > I wrong?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Donnerstag, 5. Juli 2012 11:20
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
> > @Transactional
> >
> > Why not allowing to use
> > javax.transaction.TransactionSynchronizationRegistry ?
> >
> > - Romain
> >
> >
> > 2012/7/5 Arne Limburg <arne.limburg@openknowledge.de>
> >
> > > Hi,
> > > I would not create an own module for JTA, since it will be just some
> > > lines of code after extracting an AbstractPersistenceStrategy from
> > > the ResourceLocalPersistenceStrategy.
> > >
> > > Or do we have other JTA stuff that would go into that module?
> > >
> > > Cheers,
> > > Arne
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Mark Struberg [mailto:struberg@yahoo.de]
> > > Gesendet: Donnerstag, 5. Juli 2012 11:07
> > > An: deltaspike-dev@incubator.apache.org
> > > Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
> > > @Transactional
> > >
> > > The original intent was to move all the jta stuff in an own module
> > > which would then automatically enable the JtaPersistenceStrategy.
> > >
> > >
> > > But we actually have a 3rd option:
> > >
> > > Create an AutodetectPersitenceStrategy and make this the default. It
> > > could lookup the one to take via configuration. That way a user
> > > could override according to his intention.
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: Arne Limburg <arne.limburg@openknowledge.de>
> > > > To: "deltaspike-dev@incubator.apache.org"
> > > > <deltaspike-dev@incubator.apache.org>
> > > > Cc:
> > > > Sent: Thursday, July 5, 2012 11:03 AM
> > > > Subject: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]
> > > > @Transactional
> > > >
> > > > 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