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 >>>>>>> >>>>>> >>>>> >>>> >>> >>
