geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anilkumar Gingade <aging...@pivotal.io>
Subject Re: Proposal: GEODE-4367 - Return PDXInstance when Domain Object can't be found
Date Thu, 25 Jan 2018 17:55:56 GMT
Internally, there is an option to override read-serialized flag (to true);
the query engine and other components uses this to keep the data in
serialized form and work with PdxInstance...

public static void setPdxReadSerialized(Cache cache, boolean
readSerialized);

We had discussed, making this as a public api...so that any thread that can
work on PdxInstance can take advantage of it...

-Anil.


On Thu, Jan 25, 2018 at 9:42 AM, Jacob Barrett <jbarrett@pivotal.io> wrote:

> Bruce, the flag only applies to values serialized with PDX,
> DataSerializable objects are not effected by this property.
>
> I think there is some real value here as a stop gap until we have a better
> solution in Geode 2 where the user can have a per request context that
> specifies what return type they would like. Consider the user that has an
> existing application that uses domain objects but wants to deploy another
> application that doesn't to the same Geode cluster. The only option is to
> either have all PDX deserialize to domain objects or all returned as
> PdxInstance. One of the two applications will not work without
> modification. Changing the behavior described by Addison splits the
> difference. If the application is, like it is by default, configure to
> deserialize PDX to the domain object but the domain object is not deployed
> it will now give back the PDX instance rather than failing.
>
> An explicit use case is user that has both a Java and .NET application. The
> .NET application does not have any Java domain objects to deploy to the
> server but does want to query or run server side functions. The Java
> application has deployed the domain objects to the server and distributed
> functions are written expecting those domain objects on the server. The
> user would have to create Java domain objects for the .NET application or
> modify their Java application to expect PdxInstance.
>
>
> -Jake
>
>
> On Thu, Jan 25, 2018 at 7:38 AM Bruce Schuchardt <bschuchardt@apache.org>
> wrote:
>
> > +1
> >
> > I've found the current read-serialized property to be pretty useless.
> >
> > Having said that, what if the value isn't actually in serialized form in
> > the local cache?  Is Geode supposed to serialize it & return it?  What
> > if it isn't PDX-serialized?  Do we return a byte array?
> >
> >
> > On 1/24/18 12:21 PM, Dan Smith wrote:
> > > Is this really just a workaround for the fact that the read-serialized
> > flag
> > > applies to the whole cache? I can see that if you have mix of regions
> > with
> > > and without domain classes on the server you might want this feature.
> Can
> > > you provide some more background on your use case?
> > >
> > > IMO we should get rid of read-serialized in favor of APIs that let the
> > user
> > > decide whether they get a domain class or a PdxInstance.
> > >
> > > -Dan
> > >
> > > On Wed, Jan 24, 2018 at 9:58 AM, Galen O'Sullivan <
> gosullivan@pivotal.io
> > >
> > > wrote:
> > >
> > >> Hi Addison,
> > >>
> > >> What kind of setup do you have that is causing you to have PDX
> > serialized
> > >> objects that cannot be deserialized? Do you have classes that are
> > present
> > >> on some servers but not others?
> > >>
> > >> This change would break the contract of region.get() , which is that
> it
> > >> returns a value of a type that can be put into the region.
> > >>
> > >> Returning something that isn't what the user is expecting to be in the
> > >> region would require users to check for PdxInstances every time they
> > get a
> > >> value -- even though the type annotations say that you can't get a
> > >> PdxInstance back (except for Region<Object,Object> ).
> > >>
> > >> I think it would be better to have a second API that allows users to
> get
> > >> and put PdxInstance objects in regions. That way, if they want to
> handle
> > >> the exceptional case where they have a serialized object that can't be
> > >> deserialized, they can catch the ClassNotFound exception and get the
> > >> underlying PdxInstance.
> > >>
> > >> I do think that the possibility of a ClassNotFoundException should be
> > >> documented in the Region API.
> > >>
> > >> Cheers,
> > >> Galen
> > >>
> > >> On Tue, Jan 23, 2018 at 2:56 PM, Addison Huddy <ahuddy@pivotal.io>
> > wrote:
> > >>
> > >>> Hi Geode Devs,
> > >>>
> > >>> I'm proposing the following change to how we handle deserialization
> > when
> > >>> Domain Objects can't be found and pdx-serialize=false.
> > >>>
> > >>> https://issues.apache.org/jira/browse/GEODE-4367
> > >>>
> > >>> Looking forward to the discussion.
> > >>>
> > >>> \ah
> > >>>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message