I wrote the smallest possible test case to demonstrate the problem (the
undesired updates after the commit on a transaction that only had reads).
I discovered that the way I was managing Spring Framework's transaction handling
was causing my problem.
I thought I had to supply the Spring Framework transaction manager with the
EntityManager that I was using for a thread outside Spring. However, I don't
need to. It's enough to give Spring the EntityManagerFactory.
The call to the Spring internals with the EntityManager causes the problem,
although I'm not likely to have time to check out why. This is how I was doing it:
TransactionSynchronizationManager.bindResource(
entityManagerFactory, new EntityManagerHolder(entityManager));
In this way I was assuming that Spring would use this entityManager, however for
reasons unknown Spring's JpaTransactionManager was ignoring this entityManager
and calling the EntityManagerFactory to get another - the EMF is injected into
JpaTransactionManager in the IoC config (from my ContextManager):
<bean id="transactionManager"
class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory">
<bean class="org.permacode.patternrepo.ContextManager"
factory-method="getEntityManagerFactory" />
</property>
</bean>
So OpenJPA's EntityManagerFactory provides a single EntityManager to a single
thread - presumably storing it in a ThreadLocal - rather than creating a new one
with entityManagerFactory.createEntityManager().
I presume this is an OpenJPA feature, because I didn't find it in the
persistence specification.
What do you OpenJPA developers think?
thanks
Adam
Adam Hardy on 19/12/07 12:53, wrote:
Will an Eclipse project be fine for the OpenJPA developers? How about
the lib jars? Will m2eclipse and maven be acceptable (certainly would be
easiest)?
Marc - are you using Spring Framework transaction management?
regards
Adam
Marc Siegel on 18/12/07 14:44, wrote:
It would be worth it to some of us users. Anything that could be done
to get this fixed would help many people.
-Marc
On Dec 17, 2007 6:34 PM, Adam Hardy <[EMAIL PROTECTED]> wrote:
I also had a situation where OpenJPA fired updates on unchanged
entities after
committing the transaction, for all fields all the time.
For instance, one pojo only had 2 string fields and a Long primary
key. OpenJPA
updated both string fields after the commit.
I'm using the extended persistence context without any versioning,
and the only
configuration I set is the JDBC connection properties.
Unfortunately I fixed it without figuring out where exactly the
problem was.
Sorry. I think what I had done is to begin a transaction, commit it,
and then
start another and whatever I pulled into the second transaction,
OpenJPA did an
update on.
If you think this is worth putting a test case together for, let me
know. I
wasn't quite sure whether running a second transaction after the
first on the
same entity manager was legitimate according to the JPA spec.
Shelley <[EMAIL PROTECTED]> writes:
I am seeing a similar issue with OpenJPA unnecessarily calling an
UPDATE on
every commit.
It appears that on every commit(), all of my entity's Date fields
(TemporalType.TIMESTAMP) are being updated even though they have not
changed.
UPDATE MY_ENTITY SET timeField = ?, version = ? WHERE id = ? AND
version = ?
[params=(Timestamp) 2007-12-05 15:08:18.927, (int) 2, (int) 50,
(int) 1]
My current workaround is to clear the persistence context after each
commit,
but this obviously is not desirable and shouldn't be necessary. Any
ideas
as to why this might be occurring, or how to prevent it? I am using
the
majority of default OpenJPA properties (version LockManager, optimistic
locking, etc), although I have attempted to modify some of these
properties
to prevent this problem, so far with no success.
