openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Stultz <>
Subject Re: SingleFieldManager.preFlushPC
Date Fri, 28 Aug 2009 19:59:09 GMT
On Fri, Aug 28, 2009 at 3:37 PM, Michael Dick <>wrote:

> Lets just look at your example for now though and I'll try not to muddy the
> waters any more.

I may be muddying the waters myself as this test case is not the source of
my woes, you just mentioned it doesn't look right. It is not the thing
that's causing the original exception.

> ScheduledAssignment saOne = setup.insertScheduledAssignment(...);
> >
> saOne is persisted and committed in a separate transaction?


> > em.getTransaction().begin();
> > em.merge(entry);
> > em.getTransaction().commit(); // expected this to fail, but it works
> >
> Aha, you're calling em.merge which is slightly different than em.persist.

Since this isn't the case that causes the original complaint, it may be
misleading you. I happen to be calling merge here, but the failing case is
probably calling persist since the exception includes PERSIST rather than
MERGE. Out of interest, I changed merge to persist and it still works.

So I think we're a bit off track now, talking about 2 different scenarios.
Back to the original exception, I have a save() method that calls either
em.persist() or em.merge() depending on the ID of the object. I assume in
the case given, em.persist() was called given that PERSIST appears in the
exception. So I am persisting an object with a property set to an object
that exists in the database and is currently detached without any Cascade
setting. It works most of the time but has failed with the original

I'm not sure yet if I fully understand what an unmanaged object is. Can you
read back a couple posts and answer the outstanding questions?

Thanks for your help.

Daryl Stultz
6 Degrees Software and Consulting, Inc.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message