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