Re: detachable vs non detachable classes serialization compatible

Tue, 08 May 2007 03:53:43 -0700 

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 <[EMAIL PROTECTED]>:


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 <[EMAIL PROTECTED]>:


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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!








Craig Russell

Architect, Sun Java Enterprise System http://java.sun.com/products/ 
jdo

408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!








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




Attachment:
smime.p7s

Description: S/MIME cryptographic signature






















					Reply via email to