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 >
