Vladimir, Agree, I've just forget about queries :)
On Thu, Dec 13, 2018 at 5:28 PM Vladimir Ozerov <voze...@gridgain.com> wrote: > Andrey, > > We will not be able to cache the whole data set locally, as it potentially > lead to OOME. We will have this only as an option and only for non-SQL > updates. Thus, similar semantics is not possible. > > On Thu, Dec 13, 2018 at 4:56 PM Andrey Mashenkov < > andrey.mashen...@gmail.com> > wrote: > > > Roman, > > > > We have a ticket to improve repeatable_read mode [1] via caching entries > > locally. > > This should make mvcc transaction repeatable_read semantic similar to > > non-mvcc Txs > > and allow us to implement eviction in correct way. > > > > Another way is to introduce mvcc shared (read) entry locks and evict only > > entries if no one hold any lock on it, > > but this looks tricky and error prone as your first one as it may lead to > > eviction policy unexpected behavior, > > e.g some versions can be visible while others - no (evicted). > > > > [1] https://issues.apache.org/jira/browse/IGNITE-7371 > > > > On Thu, Dec 13, 2018 at 4:34 PM Ilya Kasnacheev < > ilya.kasnach...@gmail.com > > > > > wrote: > > > > > Hello! > > > > > > Is it possible to 'touch' entries read by MVCC transactions to ensure > > that > > > they are considered recent and therefore are almost never targeted by > > > eviction? > > > > > > This is 1) with benefits. > > > > > > Regards, > > > -- > > > Ilya Kasnacheev > > > > > > > > > чт, 13 дек. 2018 г. в 16:22, Roman Kondakov <kondako...@mail.ru.invalid > > >: > > > > > > > Hi igniters, > > > > > > > > I need your advice with the following issue. When in-memory cache > > > > reaches it's memory limit, some data may be purged to avoid OOM > error. > > > > This process is described in [1]. For MVCC caches this eviction may > > > > break repeatable read semantics. For example, if transaction reads > key > > > > before eviction, this key is visible for it. But if key is evicted > some > > > > time later, this key become invisible to anyone, including our > > > > transaction, which means broken repeatable read semantics. > > > > > > > > Now we see the following solutions of this problem: > > > > > > > > 1. Ignore broken repeatable read semantics. If cache is set to allow > > > > data eviction, it may lose it's data. This means that there is no > > > > valuable information stored in cache and occasional repeatable read > > > > violations can be tolerated. > > > > > > > > 2. Prohibit eviction of MVCC caches at all. For example, stop writing > > to > > > > caches and throw an appropriate exception in the case when there is > no > > > > free space in page memory. Before this exception Ignite should do > it's > > > > best to avoid this situation, for example, evict all non-mvcc caches > > and > > > > run full vacuum to free as much space as possible. > > > > > > > > First approach is bad because it leads to cache consistency > violation. > > > > Second approach is bad because it's behavior may be unexpected to > user > > > > if he has set an eviction policy for cache, but instead of eviction > > > > Ignite trying to avoid it as much as possible. > > > > > > > > IMO first approach looks better - it is much simpler to implement and > > > > met user expectations in all points except possible repeatable read > > > > violations. > > > > > > > > What do you think? > > > > > > > > > > > > [1] https://apacheignite.readme.io/docs/evictions > > > > > > > > -- > > > > Kind Regards > > > > Roman Kondakov > > > > > > > > > > > > > > > > > -- > > Best regards, > > Andrey V. Mashenkov > > > -- Best regards, Andrey V. Mashenkov
