> is there any debugging code I could put in to reveal clues? PersistenceCapable pc = ImplHelper.toPersistenceCapable(foo, null); print(pc + ".isDetached() = " + pc.pcIsDetached()); print(pc + ".getDetachedState() = " + Arrays.toString((Object[])pc.pcGetDetachedState());
Daryl Stultz wrote: > > On Mon, Jan 4, 2010 at 12:59 PM, Pinaki Poddar <[email protected]> wrote: > >> . I am asking these >> questions to figure out at what point OpenJPA went off track in >> determining >> the detached instance as persistent-new. >> > > Ah, very well. > > >> Does these Foo/Bar instances have a Version field? > > > No, I'm not using a version field on any entities. I know it's better to > do > that, but I'm slowly porting a legacy system and don't have a solution for > dealing with version conflicts. As well, I set > <property name="openjpa.LockManager" value="none" /> > >> >> If you want to probe it further by yourself, do the following: >> 1. decompile th enhanced classes. >> 2. see the generated code for pcGetDetachedState() method. This is the >> method that is used to determine whether an input argument (or reachable) >> instance during merge() is detached or not. >> > > Ok, I'll take a look. Since I can't reproduce the problem, is there any > debugging code I could put in to reveal clues? > > -- > 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-tp4249977p4251427.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
