Hi, > 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. > 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 3. Tell OpenJPA to use a special implementation of the org.apache.openjpa.ee.ManagedRuntime interface, which you would need to at least partially implement to provide access to the Spring TransactionManager. Does this make sense? -Patrick On Nov 10, 2007 12:27 PM, Adam Hardy <[EMAIL PROTECTED]> wrote: > So I'm not the only one then. > > I just hit another issue at the data access layer/DAOs. According to the > OpenJPA > docs, the idiomatic design for the data access layer is to use an injectable > Entity Manager Factory which provides a fresh Entity Manager each time. > > 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. > > Or openjpa.TransactionMode=managed allows us to rely on the > EntityManagerFactory > to retrieve the current Entity Manager for whatever transaction is running - > i.e. container-managed transactions. > > However in our case it needs to be able to find the Spring transaction manager > (or other non-EJB transaction manager) and I've no idea whether it can. > Perhaps > Spring Frameworks have already coded up a class that provides a static method > or > a JNDI context where OpenJPA can retrieve the current Entity Manager. > > 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. > > Regards > Adam > > > Wes Wannemacher on 10/11/07 18:37, wrote: > > Adam, > > > > I'm interested in this as well, I'm trying to build a Struts2 app to > > be distributed that provides a "best-practices" example of JPA in > > struts2 (a refactoring of the struts-mailreader for those who are > > familiar with it). I want to keep Spring out, so I was thinking of > > adapting the OpenSessionInView interceptor that people use with > > Hibernate. > > > > -Wes > > > > On 11/10/07, Adam Hardy <[EMAIL PROTECTED]> wrote: > >> I need transactions in my webapp using the OpenSessionInView filter > >> pattern to > >> enable use of entities in my JSPs. > >> > >> I am not using an EJB3 container, and I am restricting my use of Spring, > >> or at > >> least trying to, to the IoC and transaction manager (for XML transaction > >> configuration). > >> > >> Is there a recognised JPA mechanism or pattern or an open-source framework > >> for > >> non-EJB container transactions for this: > >> > >> (1) servlet filter starts an EntityManager for a thread > >> (2) stores it in a ThreadLocal > >> (3) passes it to the transaction manager (Spring at the moment) > >> (4) lets JSPs run > >> (5) commits or gets Spring tx manager to commit / rollback etc > >> > >> I am currently stripping down Spring-web's OpenEntityManagerInViewFilter > >> but if > >> there is another lightweight transaction framework out there which fits > >> well > >> with JPA, it'd be preferable. > > -- Patrick Linskey 202 669 5907
