I like the idea of having PersistentMemoryPolicy configuration class. Vladimir, Yakov, any objections?
2017-09-13 3:05 GMT+03:00 Denis Magda <dma...@apache.org>: > I would go for PersistentMemoryPolicyConfiguration way if it will be > expanded by storage related settings furthers. > > For instance, from the discussion on @user I see a raising demand for the > storage maximum size. If it’s reached the data will be evicted from there > too. Just as an example. > > — > Denis > > > On Sep 12, 2017, at 2:01 PM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > > To extend on the idea of 2 different policies for memory and persistence, > > can we have 2 completely different configuration classes? > > > > - MemoryPolicy > > - PersistentMemoryPolicy (extends MemoryPolicy?) > > > > Every cache should be associated with either MemoryPolicy or > > PersistentMemoryPolicy, but not both. By default, caches on startup are > > associated with default MemoryPolicy. Users can always change it to some > > PersistentMemoryPolicy, if persistence needs to be enabled. > > > > If we agree on the above, do we really need a persistenceEnabled flag at > > all? > > > > D. > > > > On Tue, Sep 12, 2017 at 2:57 AM, Alexey Goncharuk < > > alexey.goncha...@gmail.com> wrote: > > > >> We surely can, but: > >> * we should then have two configuration settings for default memory > policy > >> size (one in-memory and one persisted) > >> * a user still may configure multiple custom memory policies. In this > >> case, the requirement to have this flag the same in a memory policy is > >> still valid, so a user still can get exceptions. > >> > >> 2017-09-12 12:44 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > >> > >>> Alex, > >>> > >>> Can we have two default memory policies - one for in-memory and another > >> one > >>> for persistence cases? > >>> > >>> On Tue, Sep 12, 2017 at 12:40 PM, Alexey Goncharuk < > >>> alexey.goncha...@gmail.com> wrote: > >>> > >>>> This is possible, but then if two caches belong to the same memory > >>> policy, > >>>> they must be both either persistence-enabled or persistence-disabled. > >> We > >>>> can add this validation, but I think this will lead to a greater > >>> confusion > >>>> for a user. > >>>> > >>>> 2017-09-12 12:34 GMT+03:00 Pavel Tupitsyn <ptupit...@apache.org>: > >>>> > >>>>> Agree with Vladimir. > >>>>> > >>>>> Currently we enable persistence cluster-wide by setting > >>>>> IgniteConfiguration.persistentStoreConfiguration. > >>>>> Ideally CacheConfiguration.persistenceEnabled should be the only > >>>> setting I > >>>>> need to set. > >>>>> > >>>>> Thanks, > >>>>> Pavel > >>>>> > >>>>> On Tue, Sep 12, 2017 at 12:28 PM, Vladimir Ozerov < > >>> voze...@gridgain.com> > >>>>> wrote: > >>>>> > >>>>>> As a user I would definitely prefer to control persistence through > >>> flag > >>>>> on > >>>>>> cache configuration. I do not even want to know what "memory > >> policy" > >>>> is. > >>>>>> E.g. CacheConfiguration.persistenceEnabled. > >>>>>> > >>>>>> On Tue, Sep 12, 2017 at 12:24 PM, Alexey Goncharuk < > >>>>>> alexey.goncha...@gmail.com> wrote: > >>>>>> > >>>>>>> Igniters, > >>>>>>> > >>>>>>> I am currently reviewing a change allowing to enable persistence > >>> on a > >>>>>>> per-memory-policy basis (thanks to K. Dudkov!) and have a > >> question > >>>>>>> regarding the changes in configuration. > >>>>>>> > >>>>>>> The suggested change is to add a flag "persistenceEnabled" > >>> (defaults > >>>> to > >>>>>>> true) to the memory policy configuration. To keep configuration > >>>>>>> compatibility, the logic is as follows: > >>>>>>> > >>>>>>> If PersistentStoreConfiguration is set, then only memory policies > >>>> with > >>>>>>> persistenceEnabled=true flag will be persisted, which is > >> consistent > >>>>> with > >>>>>>> the current behavior. To disable persistence, persistenceEnabled > >>> flag > >>>>>>> should be explicitly set to false. > >>>>>>> > >>>>>>> If PersistentStoreConfiguration is not set, then all caches are > >>>> stored > >>>>>>> in-memory and persistenceEnabled is ignored. > >>>>>>> > >>>>>>> While personally, I like this change, I would like to check if > >>> there > >>>>> are > >>>>>>> any thoughts or objections to this approach. > >>>>>>> > >>>>>>> -- > >>>>>>> Thanks, > >>>>>>> AG > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > >
