db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Bengtson <e...@jpox.org>
Subject Re: detachable vs non detachable classes serialization compatible
Date Tue, 08 May 2007 17:57:17 GMT
Craig,

I don't mean any changes to attachment or detachment detection. Once the
jdoDetachedState is lost, attachment will not work.

My proposition (serialization) is already a mechanism that works by the JDO 2
spec, and just need a clarification to the spec saying that if the user adds
the serialVersionId it becomes compatible (enhanced vs non-enhanced), but the
jdoDetachedState is lost.

Regards,

Quoting Craig L Russell <Craig.Russell@Sun.COM>:

> 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