Re: Storing object in deserialized form in geode cache

[Deepak Dixit]

Thanks Darrel and Michael for your suggestion and will evaluate which suits
best for our use case.

-
Deepak





On Thu, Mar 9, 2017 at 3:42 AM, Darrel Schneider 
wrote:

> Mike is correct that the first time you ask a VMCachedDeserializable for
> the deserialized value that the deserialized value will "stick" in the
> VMCachedDeserializable. If anyone then asks that VMCachedDeserializable for
> the serialized value it has to serialize it each time since it is now stuck
> as deserialized.
>
> Instead of doing inplace modification you might want to check out geode's
> Delta interface. It keeps the values in object form and allows the value to
> be distributed to be a subset of the full object that will be applied to
> the full object on other members.
>
> Also off-heap regions always store their values serialized.
>
> If your value is a "byte []" then it will not be wrapped by a
> VMCachedDeserializable. For "byte []" geode just stores a reference to the
> byte array.
>
> You might also want to checkout geode PDX serialization. It allows you to
> keep the data serialized on the server and still be able to fetch and
> modify fields on the serialized data.
>
> On Wed, Mar 8, 2017 at 10:41 AM, Michael Stolz  wrote:
>
> > The rule is, if you deserialize the object in the server side, Geode
> keeps
> > the deserialized version of it around.
> >
> > As for updating in place...this is the position that the docs for
> > Commercial GemFire take on that subject:
> >
> > "If you do not have the cache copy-on-read attribute set to true, do not
> > change the objects returned from the Java entry access methods. Instead,
> > create a copy of the object, then modify the copy and pass it to the Java
> > put method. Modifying a value in place bypasses the entire distribution
> > framework provided by GemFire, including cache listeners and expiration
> > activities, and can produce undesired results."
> >
> > Of course if that's exactly the behavior you WANT, then set
> > copy-on-read=false.
> >
> >
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771
> >
> > On Wed, Mar 8, 2017 at 1:37 AM, Deepak Dixit 
> > wrote:
> >
> > > Hello Geode Team,
> > >
> > > I am working on a use case where I want to store the java object. I
> want
> > to
> > > avoid the serialization and deserialization while reading on server
> > > (function execution).
> > > Also while updating I would like to update in-place rather than to
> create
> > > copy of object, modify and store it again in underlying map.
> > >
> > > Based on my current understanding, every object is wrapped in
> > > "VMCachedDeserializable" and serialized / deserialized while doing
> > get/put.
> > >
> > > Kindly advice the way with which I can store object in deserialized
> form
> > in
> > > cache and do in place modifications.
> > >
> > > Thanks,
> > > Deepak
> > >
> >
>



-- 
From:

Deepak D Dixit
deepakdixit2...@gmail.com
+919028507537

Re: Storing object in deserialized form in geode cache

[Darrel Schneider]

Mike is correct that the first time you ask a VMCachedDeserializable for
the deserialized value that the deserialized value will "stick" in the
VMCachedDeserializable. If anyone then asks that VMCachedDeserializable for
the serialized value it has to serialize it each time since it is now stuck
as deserialized.

Instead of doing inplace modification you might want to check out geode's
Delta interface. It keeps the values in object form and allows the value to
be distributed to be a subset of the full object that will be applied to
the full object on other members.

Also off-heap regions always store their values serialized.

If your value is a "byte []" then it will not be wrapped by a
VMCachedDeserializable. For "byte []" geode just stores a reference to the
byte array.

You might also want to checkout geode PDX serialization. It allows you to
keep the data serialized on the server and still be able to fetch and
modify fields on the serialized data.

On Wed, Mar 8, 2017 at 10:41 AM, Michael Stolz  wrote:

> The rule is, if you deserialize the object in the server side, Geode keeps
> the deserialized version of it around.
>
> As for updating in place...this is the position that the docs for
> Commercial GemFire take on that subject:
>
> "If you do not have the cache copy-on-read attribute set to true, do not
> change the objects returned from the Java entry access methods. Instead,
> create a copy of the object, then modify the copy and pass it to the Java
> put method. Modifying a value in place bypasses the entire distribution
> framework provided by GemFire, including cache listeners and expiration
> activities, and can produce undesired results."
>
> Of course if that's exactly the behavior you WANT, then set
> copy-on-read=false.
>
>
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Wed, Mar 8, 2017 at 1:37 AM, Deepak Dixit 
> wrote:
>
> > Hello Geode Team,
> >
> > I am working on a use case where I want to store the java object. I want
> to
> > avoid the serialization and deserialization while reading on server
> > (function execution).
> > Also while updating I would like to update in-place rather than to create
> > copy of object, modify and store it again in underlying map.
> >
> > Based on my current understanding, every object is wrapped in
> > "VMCachedDeserializable" and serialized / deserialized while doing
> get/put.
> >
> > Kindly advice the way with which I can store object in deserialized form
> in
> > cache and do in place modifications.
> >
> > Thanks,
> > Deepak
> >
>

Re: Storing object in deserialized form in geode cache

[Michael Stolz]

The rule is, if you deserialize the object in the server side, Geode keeps
the deserialized version of it around.

As for updating in place...this is the position that the docs for
Commercial GemFire take on that subject:

"If you do not have the cache copy-on-read attribute set to true, do not
change the objects returned from the Java entry access methods. Instead,
create a copy of the object, then modify the copy and pass it to the Java
put method. Modifying a value in place bypasses the entire distribution
framework provided by GemFire, including cache listeners and expiration
activities, and can produce undesired results."

Of course if that's exactly the behavior you WANT, then set
copy-on-read=false.



--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Wed, Mar 8, 2017 at 1:37 AM, Deepak Dixit 
wrote:

> Hello Geode Team,
>
> I am working on a use case where I want to store the java object. I want to
> avoid the serialization and deserialization while reading on server
> (function execution).
> Also while updating I would like to update in-place rather than to create
> copy of object, modify and store it again in underlying map.
>
> Based on my current understanding, every object is wrapped in
> "VMCachedDeserializable" and serialized / deserialized while doing get/put.
>
> Kindly advice the way with which I can store object in deserialized form in
> cache and do in place modifications.
>
> Thanks,
> Deepak
>

Storing object in deserialized form in geode cache

[Deepak Dixit]

Hello Geode Team,

I am working on a use case where I want to store the java object. I want to
avoid the serialization and deserialization while reading on server
(function execution).
Also while updating I would like to update in-place rather than to create
copy of object, modify and store it again in underlying map.

Based on my current understanding, every object is wrapped in
"VMCachedDeserializable" and serialized / deserialized while doing get/put.

Kindly advice the way with which I can store object in deserialized form in
cache and do in place modifications.

Thanks,
Deepak