LOCAL cache serializes the entries?

[Andrey Kornev]

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
     

[dsetrakyan]

On Thu, Nov 5, 2015 at 6:44 AM, Andrey Kornev <[hidden email]>
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
>

[Andrey Kornev]

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: [hidden email]
> Date: Thu, 5 Nov 2015 17:34:28 -0800
> Subject: Re: LOCAL cache serializes the entries?
> To: [hidden email]
>
> On Thu, Nov 5, 2015 at 6:44 AM, Andrey Kornev <[hidden email]>
> 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
> >

     

[dsetrakyan]

On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev <[hidden email]>
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?

[Andrey Kornev]

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: [hidden email]
> Date: Sat, 7 Nov 2015 00:32:37 -0800
> Subject: Re: LOCAL cache serializes the entries?
> To: [hidden email]
>
> On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev <[hidden email]>
> 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?

     

[dsetrakyan]

On Sat, Nov 7, 2015 at 8:28 AM, Andrey Kornev <[hidden email]>
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: [hidden email]
> > Date: Sat, 7 Nov 2015 00:32:37 -0800
> > Subject: Re: LOCAL cache serializes the entries?
> > To: [hidden email]
> >
> > On Fri, Nov 6, 2015 at 7:44 AM, Andrey Kornev <[hidden email]>
> > 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?
>
>