db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: detachable vs non detachable classes serialization compatible
Date Tue, 08 May 2007 10:53:10 GMT
Hi Erik,

The way to send objects to a remote site using the standard  
serialization contract is to define the classes as not detachable.

We looked at the issue of detaching and attaching instances of  
classes that had no detachment information very early in the JDO 2.0  
cycle and concluded that there was no standard way to detect changes  
and know whether nulls meant "not loaded" or "no reference".

If you are working with simple instances where detachment information  
is not needed, then you can use non-detachable classes. Then the  
primary issue is detecting that an instance is detached, not new.

By the way, the Java Persistence specification is quite vague on all  
of the above issues, and in my opinion does not solve the problem.

If you want to propose some standard behavior that allows an  
implementation to reliably determine whether an instance of a non- 
detachable  class is detached, that's the place to start. You might  
try to come up with some algorithm using the optional version field  
and optional primary key field and might have some luck.

As I recall, there are no TCK tests that try to detach instances of  
non-detachable classes and later attach the instances. So there is no  
gotcha there.

Craig

On May 7, 2007, at 11:26 PM, Erik Bengtson wrote:

> Craig,
>
> The use case is a remote application that does have jdo.jar in the  
> classpath.
> This application invoke RMI operations to a server where enhanced  
> objects are
> returned, but the application has an un-enhanced version of the class.
>
> Regards,
> Quoting Craig L Russell <Craig.Russell@sun.com>:
>
>> Hi Erik,
>>
>> These are implementation details. Can you explain what the user
>> behavior is, and the use case?
>>
>> Thanks,
>>
>> Craig
>>
>> On May 7, 2007, at 5:31 PM, Erik Bengtson wrote:
>>
>>> Craig,
>>>
>>> There are two cases: Classes using default Serialization and
>>> classes with User
>>> Serialization Code.
>>>
>>> In all cases the User must add serialVersionId field to the non
>>> enhanced class.
>>>
>>> Default Serialization:
>>>
>>> The default serialization will take care of dropping the
>>> jdoDetachedState. The
>>> enhancer adds the following:
>>>
>>> private writeObject (OutputStream os) //enhanced
>>> {
>>> jdoPreSerialize();
>>> os.defaultWriteObject()
>>> }
>>>
>>> User Serialization (user defined writeObject and readObject  
>>> methods):
>>>
>>> private writeObject (OutputStream os)
>>> {
>>> jdoPreSerialize(); //enhanced
>>> //user serialization
>>> os.writeObject(jdoDetachedState) //enhanced
>>> }
>>>
>>> private readObject (OutputStream os)
>>> {
>>> //user serialization
>>> jdoDetachedState = os.readObject(); //enhanced
>>> }
>>>
>>>
>>>
>>> Quoting Craig L Russell <Craig.Russell@sun.com>:
>>>
>>>> Hi Erik,
>>>>
>>>> It would help if you could explain what you have in mind with this
>>>> change. The decision to make the detachable serialization contract
>>>> incompatible was deliberate, and the objective is to guarantee that
>>>> attaching a detached instance behaves correctly.
>>>>
>>>> If you want a detached instance simply to send it away and never
>>>> expect to see it again, your proposal might be of interest. Is that
>>>> what you had in mind?
>>>>
>>>> Do you have some ideas on how to implement this feature? Seems that
>>>> if the unenhanced class is given an input stream with the detached
>>>> info in the serialized form of the instance, it's going to run into
>>>> an exception (unless you modify the unenhanced class, perhaps  
>>>> with a
>>>> byte-code enhancer).
>>>>
>>>> Thanks,
>>>>
>>>> Craig
>>>>
>>>> On May 6, 2007, at 5:39 AM, Erik Bengtson wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The spec says classes that detachable and non detachable classes
>>>>> are not
>>>>> compatible intentionally. I would like to propose a change to this
>>>>> behavior and
>>>>> let the “jdoDetachedState” lose on unmarshalling.
>>>>>
>>>>> From:
>>>>> "Classes marked as Detachable are not serialization-compatible  
>>>>> with
>>>>> un-enhanced
>>>>> classes. This is intentional, and requires that the enhanced
>>>>> version of the
>>>>> class be used wherever the instance might be instantiated."
>>>>>
>>>>> To:
>>>>> "Classes marked as Detachable are not serialization-compatible  
>>>>> with
>>>>> un-enhanced
>>>>> classes. When unmarshalling a detached object with an un-enhanced
>>>>> version of
>>>>> the class, the detached state is dropped and no further read or
>>>>> change tracking
>>>>> will occur on the unmarshalled instance."
>>>>>
>>>>> Regards,
>>>>>
>>>>> Erik Bengtson
>>>>
>>>> Craig Russell
>>>> Architect, Sun Java Enterprise System http://java.sun.com/products/
>>>> jdo
>>>> 408 276-5638 mailto:Craig.Russell@sun.com
>>>> P.S. A good JDO? O, Gasp!
>>>>
>>>>
>>>
>>>
>>>
>>
>> Craig Russell
>> Architect, Sun Java Enterprise System http://java.sun.com/products/ 
>> jdo
>> 408 276-5638 mailto:Craig.Russell@sun.com
>> P.S. A good JDO? O, Gasp!
>>
>>
>
>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message