Hi Daryl, What is the strategy used to generate primary key values for model.Foo and model.Bar? And how the primary key values were assigned to the offending instances?
Daryl Stultz wrote: > > Hello, > > I've been dogged with this error for some time: > > org.apache.openjpa.persistence.InvalidStateException: Encountered > unmanaged > object in persistent field "...model.Foo" during flush. However, this > field > does not allow cascade persist. Set the cascade attribute for this field > to > CascadeType.PERSIST or CascadeType.ALL (JPA annotations) or "persist" or > "all" (JPA orm.xml), or enable cascade-persist globally, or manually > persist > the related field value prior to flushing. You cannot flush unmanaged > objects or graphs that have persistent associations to unmanaged objects. > FailedObject: ...model.Foo-8729 > at > org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:754) > at > org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:594) > at > org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562) > at > org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478) > at > org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2829) > at > org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:39) > at > org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:960) > > The failed object is never "new" as the error message suggests. It is > always > existing and detached. The condition is not repeatable. I've been able to > reproduce the stack trace by holding the FailedObject managed by em1 and > trying to associate it with another object and persist the other object in > em2. I even had a plausible explanation for how such a condition could > occur > in my application. I'm ready to throw that idea out as I just got this: > > org.apache.openjpa.persistence.InvalidStateException: The generated value > processing detected an existing value assigned to this field: ... > model.Bar.id <http://model.Foo.id>. This existing value was either > provided > via an initializer or by calling the setter method. You either need to > remove the @GeneratedValue annotation or modify the code to remove the > initializer processing. > at > org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:483) > at > org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:463) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:744) > at > org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:134) > at > org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:520) > at > org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2824) > at > org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:39) > at > org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:960) > > This exception was thrown by the web application. The instance of Bar was > created by SOAP interface, the point being the user that crashed the app > could not have created the Bar instance. It appears the Bar instance now > has > a "new" state indicated by: > at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:39) The > stack traces for the various occurrences of the first error don't always > include the line with PNewState but usually do. > > The idea that an existing, detached object could have its state reset to > "new" could explain both errors, I think. Has anyone else seen this sort > of > thing or possibly suggest how I could expose it in a unit test? > > Thanks. > > -- > Daryl Stultz > _____________________________________ > 6 Degrees Software and Consulting, Inc. > http://www.6degrees.com > mailto:[email protected] > > ----- Pinaki -- View this message in context: http://n2.nabble.com/PC-object-losing-state-tp4249977p4251008.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
