> No, I'd rather keep Spring away from managing the persistence unit. There's > alot > I want to be able to do with it that doesn't fit in with the way Spring > handles > it. The DAO abstract superclass from Spring is quite restrictive, and combined > with the testing, it sucks the unwary into coupling their application testing > far too tightly with Spring.
FWIW, Spring's DAO approach is definitely not the only way to use OpenJPA and Spring together. I'm not a big fan of that approach, either; I prefer Spring's LocalContainerEntityManagerFactoryBean approach, which just makes a Spring-managed EMF available for injection into other Spring managed beans. Of course, there still might be things that you want to do that Spring's integration won't allow, or any number of other reasons why you want to be doing the lifecycle management on your own. I just want to make sure that you're aware that there are non-DAO approaches to their integration. -Patrick On Nov 10, 2007 3:55 PM, Adam Hardy <[EMAIL PROTECTED]> wrote: > Patrick Linskey on 10/11/07 21:15, wrote: > >> if openjpa.TransactionMode=local, we have to deal with the transactions in > >> the > >> data access layer. But this is not what I want to do - I'd like my 'non-EJB > >> transaction manager of choice' (currently Spring) to manage them. > > > > There are a few different concepts at play here. One is the > > transaction manager (Spring in your case). Another is the "persistence > > container" (Spring can do that, or a Java EE server, but it sounds > > like you're planning to create your own featherweight persistence > > container (the term "lightweight" is a bit overloaded these days) that > > handles transactions somewhere above the data tier. A third is your > > data access code. > > > > If you were deploying in an environment where you were using Spring > > for managing the persistence unit, then the Spring transaction manager > > integration would happen automatically. > > No, I'd rather keep Spring away from managing the persistence unit. There's > alot > I want to be able to do with it that doesn't fit in with the way Spring > handles > it. The DAO abstract superclass from Spring is quite restrictive, and combined > with the testing, it sucks the unwary into coupling their application testing > far too tightly with Spring. > > > > > >> Without anyone else's input on this, I'm going to look further down this > >> route: > >> providing OpenJPA with the means to get at the managed transactions / > >> entity > >> managers. > >> > >> Do you know whether this is OpenJPA functionality only or if it's > >> specified in > >> the EJB JPA specification? I'd like to be able to say that I can swop > >> OpenJPA > >> for any other JPA provider with only configuration changes necessary. > > The JPA spec doesn't define how a persistence provider should go about > > obtaining the JTA transaction. With OpenJPA, there are a number of > > configuration-based means to set this up; I would expect the same to > > be the case for other persistence providers. > > > > In OpenJPA, you can do one of the following: > > > > 1. Specify a JNDI location where the TransactionManager can be found > > > > 2. Tell OpenJPA to use the TransactionSynchronizationManager, which > > should be registered at java:comp/TransactionSynchronizationRegistry > > per the Java EE 5 spec > > OK, now we're cooking. Spring Frameworks provides a > TransactionSynchronizationManager. I'll see if I can bind onto it. > > -- Patrick Linskey 202 669 5907
