On Sat, Nov 7, 2015 at 8:28 AM, Andrey Kornev <andrewkor...@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: dsetrak...@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 <andrewkor...@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? > >
