Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: pass (athena.apache.org: domain of marc.siegel.17@gmail.com
 designates 209.85.142.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=HuqBJXAgCNxXfidFXsxCgWesqMovzrp5Hwz6b3cZ/NuMAReFCBRBHgUJkqwhGEE10lkgISr8GIblXiVNFsVFwZnzBJoyYVWzEiy+3Ts/1RqSL86wtyloslyFFz8h2fOzCbYrzNG3tCshdVIXmFxlmEpCjHbanJX7mxRGiZLyRSw=
Message-ID: <2f58dd5d0712201108g46c12443l5b938490fff40b2c@mail.gmail.com>
Date: Thu, 20 Dec 2007 14:08:36 -0500
From: "Marc Siegel" <marc.siegel.17@gmail.com>
To: users@openjpa.apache.org
Subject: Re: @PreUpdate always called?
In-Reply-To: <20071220171815.GC16275@sfu.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <2f58dd5d0711011121t21e2b80fyf8dc1a16a8c998ae@mail.gmail.com>
	 <2f58dd5d0711011220m7d8b2ff3ubec63fdeeabedd0b@mail.gmail.com>
	 <7262f25e0711011501j5b843ee0l99ef04aae1cdaab0@mail.gmail.com>
	 <2f58dd5d0711011509t5e02ebffhf7accbbf70fdc77e@mail.gmail.com>
	 <14180794.post@talk.nabble.com>
	 <loom.20071217T124620-376@post.gmane.org>
	 <2f58dd5d0712180644h1fc01b3emc894a53ca1d1b50d@mail.gmail.com>
	 <4769145B.4030206@cyberspaceroad.org>
	 <476A5E0C.6050302@cyberspaceroad.org> <20071220171815.GC16275@sfu.ca>

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.
>