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:[email protected]] Gesendet: Donnerstag, 5. Juli 2012 13:00 An: [email protected] 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 <[email protected]> > 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:[email protected]] > Gesendet: Donnerstag, 5. Juli 2012 12:20 > An: [email protected] > 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 <[email protected]> > > > 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:[email protected]] > > Gesendet: Donnerstag, 5. Juli 2012 12:02 > > An: [email protected] > > Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] > > @Transactional > > > > So you forget the usage of @Transactional on CMT? > > > > - Romain > > > > > > 2012/7/5 Arne Limburg <[email protected]> > > > > > 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:[email protected]] > > > Gesendet: Donnerstag, 5. Juli 2012 11:43 > > > An: [email protected] > > > Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] > > > @Transactional > > > > > > what about resource adapters? > > > > > > - Romain > > > > > > > > > 2012/7/5 Arne Limburg <[email protected]> > > > > > > > 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:[email protected]] > > > > Gesendet: Donnerstag, 5. Juli 2012 11:31 > > > > An: [email protected] > > > > 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 <[email protected]> > > > > > > > > > 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:[email protected]] > > > > > Gesendet: Donnerstag, 5. Juli 2012 11:20 > > > > > An: [email protected] > > > > > Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] > > > > > @Transactional > > > > > > > > > > Why not allowing to use > > > > > javax.transaction.TransactionSynchronizationRegistry ? > > > > > > > > > > - Romain > > > > > > > > > > > > > > > 2012/7/5 Arne Limburg <[email protected]> > > > > > > > > > > > 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:[email protected]] > > > > > > Gesendet: Donnerstag, 5. Juli 2012 11:07 > > > > > > An: [email protected] > > > > > > 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 <[email protected]> > > > > > > > To: "[email protected]" > > > > > > > <[email protected]> > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
