http://www.atomikos.com/products.html#ate
And whatever happened to JOTM, anyway? d. --- Adam Hardy <[EMAIL PROTECTED]> wrote: > Wes Wannemacher on 12/11/07 15:05, wrote: > > I have a judgment call to make now and wanted some > input. At first I > > was hoping to create this in a non-IoC fashion. > This was simply to > > keep the dependencies at a minimum and concentrate > on integrating JPA > > and struts2. But, in many spots, the JPA docs > indicate that the > > EntityManagerFactory should be injected (although > it isn't that hard > > to instantiate by hand). I've thought about using > Spring, which will > > make things pretty easy with it's transaction > management and DI. It > > has been suggested to me to use the JpaTemplate, > but while I was > > reading the JavaDoc for it - > > > > > http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/orm/jpa/JpaTemplate.html > > > > It indicates that new projects should use a DAO > with a shared EM injected. > > > > If I make DAOs, I may skip Spring altogether. > > > > Also, I could do the transaction management in the > DAO implementations > > or try to hook into the transactional management > of an ee server. If I > > manage the transactions myself, it will make > mailreader work in non-ee > > servers as well. However, if this is a > "best-practices" example, I > > should probably use the ee server. What do you > guys think will be the > > best approach. > > Hi Wes, > > didn't we chat on the OpenJPA list about this when > we were both getting into the > subject over the weekend? I haven't had time to > finish my implementation of JPA > + S2 yet but I'm getting close. > > I think your initial instinct to keep Spring to > limited use only is good, since > adopting the Spring framework without enough > consideration invariably leads to a > completely 'Springified' app which then creates > immense inertia against moving > it in any other direction. > > One thing that interests me is the ability to plug > in any IoC container, but as > you point out it's the transaction management which > is key and it's foxing me at > the moment. > > I've tried the hard-coding route - I ended up with > 10 lines of code for every > method of which only one was business code and then > gave up because I don't want > to write my own transaction management framework. > I'm currently struggling to > use Spring but without giving in to its demands to > add in DAO superclasses and > so forth. > > Unfortunately outside EJB containers, the only > transaction management framework > I know is Spring and it's not exactly snap-on. > > Presumably for the mail-reader it's sufficient to > use transaction management in > the OpenSessionInView, hard-coded with only one type > of transaction with no > authorisation management? > > Regards > Adam > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
