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 > > > > > >
