I second this - I am NOT using Spring, and I see this behavior. -Marc
On Dec 20, 2007 12:18 PM, Tedman Leung <[EMAIL PROTECTED]> wrote: > I'm not entirely sure it's a problem with "your spring transaction usage". > > I have the exact same problem although I'm also using springs > transactions, I'm using the spring annotated transactions. > > I find that if I just call entityManager.find() on an object that once the > transaction completes it calls @PreUpdate even if I haven't modified any > fields. > > I would have assumed that a transaction.commit() would not cause > @PreUpdate to be called if no changes were made to the object. I tried > looking in the ejb-3_0 spec but it didn't seems to cleary indicate if it > should or should not be called. > > I guess I'll try writing a simple test case which shows this. > > > > > 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. > > > > > > > > > > -- > Ted Leung > [EMAIL PROTECTED] > > It is easier to speak wisely than to act wisely. >
