> 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
> I don't believe the state is ever serialized. The bottomline is when OpenJPA runtime sees the Bar instance, it has to determine whether the instance is detached or new. The mechanism available to OpenJPA are markers that it has added deliberately to the enhanced version of the class (e.g. DetachedStateField) or values of version field added by the user application. As the trace suggests > B:2436.isDetached() = false > B:2436.getDetachedState() = null OpenJPA sees neither a detached state nor a version field -- determines B to be new -- tries to enforce that B has no primary key value because it is instructed by @GeneratedValue to auto-generate the primary key -- but B does have a non-default primary key value -- and results into a long stack trace. So the process/mechanics (SOAP, deserialization whatever) that has instantiated B-2436 has to aid OpenJPA by either retaining its detach state field marker or a non-default version field value. Otherwise OpenJPA has no way to determine that B-2436 is actually a detached instance. One thing though can be argued: Existence of a non-default primary key value for an instance X that is using @GeneratedValue strategy can be a marker that X is detached rather than new. But instead of using that as a clue, this non-default pk value is prohibiting the merge. As SVN history shows OPENJPA-272 had introduced this enforcement. But I think that such enforcement should be conditional. Because available mechanics of detecting 'detached' state across serialization boundary have their downsides. a) non-transient detached field has a strong downside -- because it changes the serialization signature -- the remote client have to have access to the enhanced classes and OpenJPA libraries -- which is not always feasible. b) version field (which has to be persistent) is not always feasible for legacy reasons. Hence, we could optionally use non-default primary key values in for types that are using @GeneratedValue as a clue for detached. However, there is another option which does not require serialization signature change -- used @DeatchedState annotation on a non-persistent Object field in your domain classes. Daryl Stultz wrote: > > On Mon, Jan 4, 2010 at 2:29 PM, Daryl Stultz <[email protected]> wrote: > >> I'm wondering if this code: >> >> PersistenceCapable pc = ImplHelper.toPersistenceCapable(foo, null); >>> print(pc + ".isDetached() = " + pc.pcIsDetached()); >>> print(pc + ".getDetachedState() = " + >>> Arrays.toString((Object[])pc.pcGetDetachedState()); >>> >>> >>> adds anything to my code. Probably the last line... >> >> I've added it to my debug code. So for my unittest that produces the same > stack trace I get: > B:2436:EM:dxnPrt BK:cdxnPrt SM:null > B:2436.isDetached() = false > B:2436.getDetachedState() = null > > We'll see what the production environment turns up... > > -- > 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-tp4249977p4252272.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
