Hi,
Possibly the following causing the trouble:
The instances are crossing serialization boundary and once they are
coming back to OpenJPA managed runtime, OpenJPA not seeing any marker on
them -- and thereby identifying them as purely new instead of detached
instances. The markers that are used in detecting an instance as detached
can be a non-default value in a @version field (which you are not using) or
a DetachedStateField that OpenJPA adds to enhanced class signature. However,
the detached state field is transient by default and hence did not survive
the passage across serialization boundary.
So one possibility is to configure serialization behavior of OpenJPA
enhanced classes by configuring the added DetachedStateField as
non-transient:
<property name="openjpa.DetachState" value="DetachedStateField=true"/>
Please note that
a) after changing this configuration, you need to "touch" the domain
classes so that they get re-enhanced. Merely enhancing again without
touching them will not work because enhancer will skip already enhanced
classes.
b) the domain classes must be Serializable (but that perhaps they already
are)
c) However, looking at the enhancer code, I doubt whether enhancer is
actually honoring that configuration. So decompile and check the declaration
of a field named 'pcDetachedState' in the enhanced class.
Pinaki Poddar wrote:
>
>> 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-tp4249977p4251621.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
