openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marc Siegel" <marc.siegel...@gmail.com>
Subject Re: @PreUpdate always called?
Date Thu, 20 Dec 2007 19:08:36 GMT
I second this - I am NOT using Spring, and I see this behavior.

-Marc

On Dec 20, 2007 12:18 PM, Tedman Leung <tedman@sfu.ca> 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 <adam.sql@cyberspaceroad.org>
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 <randomshelley@...> 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
>                                                            tedman@sfu.ca
>
> It is easier to speak wisely than to act wisely.
>

Mime
View raw message