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