openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wes Wannemacher <>
Subject Re: Does merging cause all "dirty" entities to be written to the database?
Date Tue, 27 Apr 2010 13:11:24 GMT

I think the first time I posted this message, pastebin went offline,
but the unit test is back up and visible...

What I'd really like to know is whether this test should ever pass,
and if not, where can I read about the details of the merge call. If
it should pass, that would be interesting as well because I would know
to go take it up with the Spring folks.


On Fri, Apr 23, 2010 at 1:57 PM, Wes Wannemacher <> wrote:
> Hello, I've been lurking on this list for a while and i have been a
> happy user for OpenJPA for a year or so. However, I came across a
> situation recently which kind of suprised me.
> Imagine that both CDO_ConditionCode and CDO_CageCode are enhanced
> entities that do not a relationship. These beans have an @Id field (of
> type String) and a description (of type String). Here is the
> interesting snippet of a unit test I wrote to check out this behavior
> ->
> CDO_ConditionCode retrievedCondCode = em.find(CDO_ConditionCode.class, "00");
> CDO_CageCode retrievedCageCode = em.find(CDO_CageCode.class, "00000");
> retrievedCondCode.setDescription("new description");
> retrievedCageCode.setDescription("new description");
> em.getTransaction().begin();
> retrievedCageCode = em.merge(retrievedCageCode);
> // em.flush(); // with or without the flush, this test fails
> em.getTransaction().commit();
> CDO_ConditionCode otherRetrievedCondCode =
> em.find(CDO_ConditionCode.class, "00");
> assertTrue("expected value not to change", "description of
> 00".equals(otherRetrievedCondCode.getDescription()));
> I noticed it while working on an oracle database. I had a breakpoint
> in one section of my code and I was trying to figure out an unrelated
> problem. While the app was hanging at the breakpoint, I noticed that
> changes to an unmerged entity had been written to the database. If you
> want to see the full unit test, it will be available here for a little
> while -
> In the application, most of the JPA operations are hidden behind a DAO
> that delegates to Spring's JpaTemplate. However, I wrote the unit test
> to get rid of the JpaTemplate to see if hte problem was with my DAO,
> Spring or OpenJPA. In addition to removing the JpaTemplate, I also ran
> the unit test using EclipseLink 2.0.2, which failed at the assert,
> just like OpenJPA. That leads me to believe that this isn't
> necessarily a *problem*, but it is that maybe I misunderstand the
> behavior of a call to merge. Can someone explain to me why this fails,
> or just point me to a section that would help me understand why a
> merge to one entity causes the other entity to be saved to the
> database. Or, if this should succeed, I will look further at Spring
> being the culprit (even though I eliminated the JpaTemplate, I did not
> eliminate Spring's LocalContainerEntityManagerFactoryBean).
> Thanks guys!
> -Wes
> --
> Wes Wannemacher
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!

Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

View raw message