This may work. But I do not like any implicit memory policy cloning because this will double the expected memory consumption and result in questions "why does my Ignite take 2x more memory when I enable persistence" from users.
I think if we go with "persistence per cache" path, we must just enforce the correct configuration and let users configure the rest. Any implicit 'magic' will lead to confusion. 2017-09-12 13:10 GMT+03:00 Pavel Tupitsyn <ptupit...@apache.org>: > Can we leave the default policy as is, but clone it with persistence > enabled on demand? > > E.g: > - user starts Ignite with default config > - createCache without persistence - use default policy > - createCache with persistence - clone default policy with enabled > persistence and some predefined postfix > - createCache without persistence - use default policy > - createCache with persistence - reuse cloned policy > > etc etc. > > We can think of CacheConfiguration.persistenceEnabled as an override. > > On Tue, Sep 12, 2017 at 12:57 PM, 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
