You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Andrey Kornev <an...@hotmail.com> on 2015/11/05 15:44:21 UTC

LOCAL cache serializes the entries?

Hello,

It seems that even if the cache is configured as LOCAL, the entries are nevertheless stored in serialized form. If that's the case, could someone explain the reasons?

Regards
Andrey
 		 	   		  

Re: LOCAL cache serializes the entries?

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Sat, Nov 7, 2015 at 8:28 AM, Andrey Kornev <an...@hotmail.com>
wrote:

> Dmitriy,
>
> How would that help me if, for example, my cache entries held references
> to some other non-"binarylizable" ;) resources (like JDBC connection,
> socket, etc)? In other words, in my case the cache entries are not plain
> Java beans or DTOs, but rather full fledged classes with behavior, state,
> and dependencies.


Can you declare non-desirable dependencies as transient?


> Of course, there exist a proper work around for things like that, but I
> was hoping that a LOCAL cache (with copyOnGet disabled) would just work.
>

Even with copyOnGet disabled, Ignite will serialize the entity once, when
putting it in cache. Then, whenever “get” is called, it will deserialize
and cache the new reference.


>
> I feel the current implementation violates the principle of least surprise
> (https://en.wikipedia.org/wiki/Principle_of_least_astonishment).
>

Disagree. Users like to get objects from cache and then be able to change
the same reference. If we don’t create copies, all sorts of bad things
happen.


>
> Regards
> Andrey
>
> > From: dsetrakyan@apache.org
> > Date: Sat, 7 Nov 2015 00:32:37 -0800
> > Subject: Re: LOCAL cache serializes the entries?
> > To: dev@ignite.apache.org
> >
> > On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev <an...@hotmail.com>
> > wrote:
> >
> > >
> > > This design is unfortunate, but I understand the reason. My issue is
> not
> > > with performance impact of serialization, but with having to make my
> > > key/value serializable which is not always possible nor desirable.
> >
> >
> > Andrey, as you aware, in Ignite 1.5 objects will be stored in Ignite
> binary
> > format and won’t have to be Serializable. Will it work for you then?
>
>

RE: LOCAL cache serializes the entries?

Posted by Andrey Kornev <an...@hotmail.com>.
Dmitriy,

How would that help me if, for example, my cache entries held references to some other non-"binarylizable" ;) resources (like JDBC connection, socket, etc)? In other words, in my case the cache entries are not plain Java beans or DTOs, but rather full fledged classes with behavior, state, and dependencies. Of course, there exist a proper work around for things like that, but I was hoping that a LOCAL cache (with copyOnGet disabled) would just work.

I feel the current implementation violates the principle of least surprise (https://en.wikipedia.org/wiki/Principle_of_least_astonishment).

Regards
Andrey

> From: dsetrakyan@apache.org
> Date: Sat, 7 Nov 2015 00:32:37 -0800
> Subject: Re: LOCAL cache serializes the entries?
> To: dev@ignite.apache.org
> 
> On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev <an...@hotmail.com>
> wrote:
> 
> >
> > This design is unfortunate, but I understand the reason. My issue is not
> > with performance impact of serialization, but with having to make my
> > key/value serializable which is not always possible nor desirable.
> 
> 
> Andrey, as you aware, in Ignite 1.5 objects will be stored in Ignite binary
> format and won’t have to be Serializable. Will it work for you then?
 		 	   		  

Re: LOCAL cache serializes the entries?

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev <an...@hotmail.com>
wrote:

>
> This design is unfortunate, but I understand the reason. My issue is not
> with performance impact of serialization, but with having to make my
> key/value serializable which is not always possible nor desirable.


Andrey, as you aware, in Ignite 1.5 objects will be stored in Ignite binary
format and won’t have to be Serializable. Will it work for you then?

RE: LOCAL cache serializes the entries?

Posted by Andrey Kornev <an...@hotmail.com>.
Dmitriy,

This design is unfortunate, but I understand the reason. My issue is not with performance impact of serialization, but with having to make my key/value serializable which is not always possible nor desirable. Well, back to Guava's Cache!

Thanks
Andrey

> From: dsetrakyan@apache.org
> Date: Thu, 5 Nov 2015 17:34:28 -0800
> Subject: Re: LOCAL cache serializes the entries?
> To: dev@ignite.apache.org
> 
> On Thu, Nov 5, 2015 at 6:44 AM, Andrey Kornev <an...@hotmail.com>
> wrote:
> 
> > Hello,
> >
> > It seems that even if the cache is configured as LOCAL, the entries are
> > nevertheless stored in serialized form. If that's the case, could someone
> > explain the reasons?
> >
> 
> Andrey, JCache has pass-by-value semantics by default, which means that
> whenever you do a get from cache, you have to get a copy of the value, not
> the same reference. To achieve that, we must serialize value on Put, so
> that we can deserialize it on Get and get a different copy.
> 
> You have an option to set copyOnGet parameter to false, in which case
> Ignite will cache the deserialized reference after the 1st Get.
> 
> 
> >
> > Regards
> > Andrey
> >
 		 	   		  

Re: LOCAL cache serializes the entries?

Posted by Dmitriy Setrakyan <ds...@apache.org>.
On Thu, Nov 5, 2015 at 6:44 AM, Andrey Kornev <an...@hotmail.com>
wrote:

> Hello,
>
> It seems that even if the cache is configured as LOCAL, the entries are
> nevertheless stored in serialized form. If that's the case, could someone
> explain the reasons?
>

Andrey, JCache has pass-by-value semantics by default, which means that
whenever you do a get from cache, you have to get a copy of the value, not
the same reference. To achieve that, we must serialize value on Put, so
that we can deserialize it on Get and get a different copy.

You have an option to set copyOnGet parameter to false, in which case
Ignite will cache the deserialized reference after the 1st Get.


>
> Regards
> Andrey
>