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.
