Thanks for the testcase Ted. I haven't resolved the problem, but it does seem to be related to the automatic enhancement.
If I manually enhance the classes by running PCEnhancer or the ant task I don't see the problem. I believe using a javaagent to do enhancement will also work. Shelley or Marc could you verify that using the PCEnhancer resolves the issue for you as well? -Mike On Dec 20, 2007 1:08 PM, Marc Siegel <[EMAIL PROTECTED]> wrote: > 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. > > >
