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 11:55:56 GMT
right,

maybe let's go for a first version with ut and then we'll see how to try to
merge it (hope it will be done @ spec level).

- Romain


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

> OK, now I understand your point :-)
> Yes, I would suppose that @Transactional would work in that scenario, but
> I am afraid it doesn't.
> I guess the spec is not very specific about a CDI bean that is injected
> into an interceptor that is around a CMT EJB and if a UserTransaction is
> available there...
> I'll write some tests to work that out.
>
> A simple solution would be to call a BMT EJB from within the interceptor,
> which does the transaction-handling...
>
> Cheers,
> Arne
>
> -----Ursprüngliche Nachricht-----
> Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> Gesendet: Donnerstag, 5. Juli 2012 13:00
> An: deltaspike-dev@incubator.apache.org
> Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional
>
> i guess so (CMT EJB)
>
> i know that's not the first goal but could be nice to uniform the
> programming API
>
> - Romain
>
>
> 2012/7/5 Arne Limburg <arne.limburg@openknowledge.de>
>
> > From the CDI Spec:
> > "Java EE or embeddable EJB container must provide the following
> > built-in beans, all of which have qualifier @Default:
> > . a bean with bean type javax.transaction.UserTransaction, allowing
> > injection of a reference to the JTA User- Transaction,"
> > So yes, I only would support the scenarios, where a UserTransaction is
> > available. Are there any scenarios where no UserTransaction is
> > available, but a TransactionManager or a
> > TransactionSynchronizationRegistry is available?
> >
> > Cheers,
> > Arne
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Romain Manni-Bucau [mailto:rmannibucau@gmail.com]
> > 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 case 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 one thread.
> > > So either a transaction is active when the @Transactional
> > > interceptor is invoked then we should not start a new one, nor
> > > commit the existing, but set it to rollback-only on an exception.
> > > Or there is no transaction active then we should begin it and commit
> > > it afterwards.
> > > All this can be done with a UserTransaction and we would still join
> > > the CMT if available.
> > >
> > > Cheers,
> > > Arne
> > >
> > > -----Ursprüngliche 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]
> > > @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
> > > > would create an own module.
> > > > But my current focus is the integration of @Transactional and JTA
> > > > EntityManagers.
> > > > There imho the UserTransaction is a good interface to use and we
> > > > could even leave it there when we start implementing a
> > transaction-module.
> > > >
> > > > Cheers,
> > > > Arne
> > > >
> > > > -----Ursprüngliche 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]
> > > > @Transactional
> > > >
> > > > 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