Hi, I startet implementing it that way, but I stumbled over another issue: We get a dependency to the JTA spec and the EJB spec that way. So our JPA module only would work with this apis in the classpath. Do we accept this or are we back on a JTA module?
Cheers, Arne -----Ursprüngliche Nachricht----- Von: Romain Manni-Bucau [mailto:[email protected]] Gesendet: Donnerstag, 5. Juli 2012 15:07 An: [email protected] Betreff: Re: [DISCUSS] [DELTASPIKE-175] [DELTASPIKE-219] @Transactional if it works fine with CMT +1 well let's have a try, we'll fix it if it is not enough ;) - Romain 2012/7/5 Pete Muir <[email protected]> > In Seam 2 we: > > * checked if UT was available in JNDI, and used it if it were > * checked if there was a CMT transaction, and used it (IIRC this wwas > to work around abug) > * otherwise tried to use a resource local transaction (e.g. from > Hibernate) > * allowed the user to override and specify one strategy > > In Seam 3 we did the same. > > So I like option 1. > > On 5 Jul 2012, at 10:03, Arne Limburg wrote: > > > 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 > >
