openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daryl Stultz <da...@6degrees.com>
Subject PC object losing state
Date Mon, 04 Jan 2010 13:58:35 GMT
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:daryl@6degrees.com

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