Hi folks, I did not quite get what user problem we are trying to solve so far.
The simplest thing which comes to my mind is to prohibit MVCC caches creation in a data region with eviction configured. What am I missing? Why do we need this feature today? чт, 13 дек. 2018 г. в 22:33, Vladimir Ozerov <voze...@gridgain.com>: > > It's hard to believe that entries are not locked on backups, because we > wrtite data right away. Even if it so, it should be very easy to fix - just > do not evict and entry if it was created or deleted by currently active > transaction. > > On Thu, Dec 13, 2018 at 10:28 PM Roman Kondakov <kondako...@mail.ru.invalid> > wrote: > > > Vladimir, > > > > we do not lock entries on backups when MVCC is enabled and therefore we > > don't avoid entry eviction from backup by locking. So, your first > > scenario with primary stop is still relevant. > > > > > > -- > > Kind Regards > > Roman Kondakov > > > > On 13.12.2018 22:14, Vladimir Ozerov wrote: > > > No, I mean that we should think about what kind of guarantees it > > possible. > > > My proposal was to prevent evictions of locked entries. This way we can > > say > > > users: "if you want true REPEATABLE_READ when evictions are enabled, then > > > make sure to lock entries on every access". This effectively means that > > all > > > SELECT's should be replaced with "SELECT FOR UPDATE". > > > > > > On Thu, Dec 13, 2018 at 10:09 PM Roman Kondakov > > <kondako...@mail.ru.invalid> > > > wrote: > > > > > >> Vladimir, > > >> > > >> correct me please if i misunderstood your thought. So, if eviction is > > >> not about a consistency at all, we may evict keys in any way because > > >> broken repeatable read semantics is not the biggest problem here. But we > > >> should add some notes about it to user documentation. Right? > > >> > > >> > > >> -- > > >> Kind Regards > > >> Roman Kondakov > > >> > > >> On 13.12.2018 17:45, Vladimir Ozerov wrote: > > >>> Roman, > > >>> > > >>> I would start with the fact that eviction can never be consistent > > unless > > >> it > > >>> utilizes atomic broadcast protocol, which is not the case for Ignite. > > In > > >>> Ignite entries on node are evicted independently. > > >>> > > >>> So you may easily get into situation like this: > > >>> 1) Start a cache with 1 backup and FULL_SYNC mode > > >>> 2) Put a key to primary node > > >>> 3) Stop primary > > >>> 4) Try reading from new primary and get null because key was evicted > > >>> concurrently > > >>> > > >>> Or: > > >>> 1) Start a transaction in PESSIMISTIC/READ_COMMITTED mode > > >>> 2) Read a key, get value > > >>> 3) Read the same key again, get null > > >>> > > >>> So in reality the choice is not between consistent and inconsistent > > >>> behavior, but rather about degree of inconsistency. Any solution is > > >>> possible as long as we can explain it to the user. E.g. "do not evict a > > >> key > > >>> if it is either write-locked". > > >>> > > >>> > > >>> On Thu, Dec 13, 2018 at 5:19 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, Ivan Pavlukhin
