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 18:32:13 GMT
Ops,

This is already in the spec §21.6


Quoting Erik Bengtson <erik@jpox.org>:

> 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