On Fri, Aug 28, 2009 at 3:37 PM, Michael Dick <[email protected]>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? > Yes. > > 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 exception. 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. http://www.6degrees.com mailto:[email protected]
