Mailing-List: contact deltaspike-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: deltaspike-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Arne Limburg <arne.limburg@openknowledge.de>
To: "deltaspike-dev@incubator.apache.org"
	<deltaspike-dev@incubator.apache.org>
Date: Thu, 5 Jul 2012 12:27:33 +0200
Subject: AW: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
Thread-Topic: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
Thread-Index: Ac1al+Dek+VuEVKPS/OIHfxxEEZPMAAAJwqQ
References: <20120705090046.7144616464E@mx01.openknowledge.de>
 <1341479214.41027.YahooMailNeo@web171504.mail.ir2.yahoo.com>
 <20120705091243.8A9FF16464E@mx01.openknowledge.de>
 <CACLE=7NrHWQxYQsc2tihBK-+PSqXaurxMT3orZiWZAqf+BDNNQ@mail.gmail.com>
 <20120705092426.7A9F6164A83@mx01.openknowledge.de>
 <CACLE=7OrDuTmdWEmHmnG79RLfacTMtbQVxX0Fq1tvu4BR1jgzQ@mail.gmail.com>
 <20120705093832.8D92016431D@mx01.openknowledge.de>
 <CACLE=7Mgw7Bn__FpG+n_p3pQjHR2A94VsTZZ=8jieX+nHU5JFg@mail.gmail.com>
 <20120705095854.87636164B04@mx01.openknowledge.de>
 <CACLE=7Pj5nYq+-6CGVMaEkvHPdVVe3M=NgBhyY1SzE52cYKv-g@mail.gmail.com>
 <20120705101737.A388916431D@mx01.openknowledge.de>
 <CACLE=7MZUbKbtXU9a8hTBh+2mxhQWx7sBV6GdwiJ3_fp3ogARA@mail.gmail.com>
In-Reply-To: 
 <CACLE=7MZUbKbtXU9a8hTBh+2mxhQWx7sBV6GdwiJ3_fp3ogARA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-Id: <20120705102450.9AA5516431D@mx01.openknowledge.de>

>From the CDI Spec:
"Java EE or embeddable EJB container must provide the following built-in be=
ans, all of which have qualifier @Default:
. a bean with bean type javax.transaction.UserTransaction, allowing injecti=
on of a reference to the JTA User-
Transaction,"
So yes, I only would support the scenarios, where a UserTransaction is avai=
lable. Are there any scenarios where no UserTransaction is available, but a=
 TransactionManager or a TransactionSynchronizationRegistry is available?

Cheers,
Arne

-----Urspr=FCngliche Nachricht-----
Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]=20
Gesendet: Donnerstag, 5. Juli 2012 12:20
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional

you suppose the UserTransaction will always be available, that's not the ca=
se i think

- Romain


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

> What do you mean with this?
> To my understanding of JTA there is at most one Transaction active in=20
> one thread.
> So either a transaction is active when the @Transactional interceptor=20
> is invoked then we should not start a new one, nor commit the=20
> existing, but set it to rollback-only on an exception.
> Or there is no transaction active then we should begin it and commit=20
> it afterwards.
> All this can be done with a UserTransaction and we would still join=20
> the CMT if available.
>
> Cheers,
> Arne
>
> -----Urspr=FCngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Donnerstag, 5. Juli 2012 12:02
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]=20
> @Transactional
>
> So you forget the usage of @Transactional on CMT?
>
> - Romain
>
>
> 2012/7/5 Arne Limburg <arne.limburg@openknowledge.de>
>
> > This stuff is all supported when we use UserTransaction,
> >
> > When we go the route and implement features for JCA we definitely=20
> > would create an own module.
> > But my current focus is the integration of @Transactional and JTA=20
> > EntityManagers.
> > There imho the UserTransaction is a good interface to use and we=20
> > could even leave it there when we start implementing a transaction-modu=
le.
> >
> > Cheers,
> > Arne
> >
> > -----Urspr=FCngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > Gesendet: Donnerstag, 5. Juli 2012 11:43
> > An: deltaspike-dev@incubator.apache.org
> > Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219]=20
> > @Transactional
> >
> > what about resource adapters?
> >
> > - Romain
> >
> >
> > 2012/7/5 Arne Limburg <arne.limburg@openknowledge.de>
> >
> > > Ok, you are talking about javax.transaction.TransactionManager and=20
> > > javax.transaction.Transaction?
> > > The problem with this is, that the way to receive them is very=20
> > > container-dependent and we would have to maintain very much=20
> > > container-specific code.
> > > If we decide to go that way we definitely would need a separate=20
> > > JTA
> > module.
> > > But the only benefit I see is that we could suspend and resume on=20
> > > transactions...
> > > Is that worth the effort?
> > > That would be something that a user could implement in a=20
> > > container-specific way, if he needs it...
> > >
> > > Cheers,
> > > Arne
> > >
> > > -----Urspr=FCngliche 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]=20
> > > @Transactional
> > >
> > > right but i wonder about the integration with a container managed=20
> > > transactions. UserTransaction is pretty close to resource local=20
> > > 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=20
> > > > or am I wrong?
> > > >
> > > > Cheers,
> > > > Arne
> > > >
> > > > -----Urspr=FCngliche 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]=20
> > > > @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=20
> > > > > just some lines of code after extracting an=20
> > > > > AbstractPersistenceStrategy from the
> ResourceLocalPersistenceStrategy.
> > > > >
> > > > > Or do we have other JTA stuff that would go into that module?
> > > > >
> > > > > Cheers,
> > > > > Arne
> > > > >
> > > > > -----Urspr=FCngliche 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]=20
> > > > > @Transactional
> > > > >
> > > > > The original intent was to move all the jta stuff in an own=20
> > > > > 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=20
> > > > > 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]=20
> > > > > > @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=20
> > > > > > PersistenceStrategy should be taken and how should this=20
> > > > > > decision be
> > > > made?
> > > > > > I have three suggestions:
> > > > > >
> > > > > > 1.      We detect, if a UserTransaction is available, if so, th=
e
> > > > > > JtaPersistenceStrategy is taken, otherwise the=20
> > > > > > ResourceLocalPersistenceStrategy is taken.
> > > > > >
> > > > > > 2.      We detect, if the involved persistence units use JTA or
> > > > > > RESOURCE_LOCAL (which would lead to another question: Would=20
> > > > > > we like to support, that @Transactional mixes both=20
> > > > > > 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
> > > > > >
> > > > >
> > > >
> > >
> >
>