[jira] [Updated] (IGNITE-9321) MVCC: support cache events

["Maxim Muzafarov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Maxim Muzafarov updated IGNITE-9321:
------------------------------------
    Fix Version/s:     (was: 2.8)
                   2.9

> MVCC: support cache events
> --------------------------
>
>                 Key: IGNITE-9321
>                 URL: https://issues.apache.org/jira/browse/IGNITE-9321
>             Project: Ignite
>          Issue Type: Task
>          Components: mvcc
>            Reporter: Vladimir Ozerov
>            Priority: Major
>             Fix For: 2.9
>
>         Attachments: EventsProblems.java
>
>
> Currently cache events are not fired for MVCC caches. Need to restore all cache events. 
> Number of problems were found in Events framework. Let's outline them before proceeding with implementation for MVCC caches. Attached reproducer demonstrates several problems.
> h2. Bugs
> 1. {{IgniteCache.remove}} fires event regardless entry presence in the cache. 
> 2. CACHE_OBJECT_PUT can report {{hasOldValue==true,oldValue==null}} for transactional cache.
> See attached reproducer.
> Also it means that test coverage is not sufficient, negative tests could be added, event content check could be added.
> h2. Inconsistency
> In current vision for the same operations with different cache modes we will see different number of events fired. ATOMIC cache fires events for each operation. TRANSACTIONAL cache fires only final changes on commit (_put remove put_ on the same key will result in only one CACHE_OBJECT_PUT event) and nothing on rollback. Current plan for MVCC is to fire events right away with operation, so events for rolled back transactions will be fired as well. So, for all 3 modes behavior is different. It looks hardly understandable and subsequently could lead to usage errors.
> Additionally there are confusion points for SQL operations. For SELECT CACHE_QUERY_OBJECT_READ event is triggered and CACHE_OBJECT_READ is not. For DML operations weird mix of events occurs.
> h2. Use cases
> Also it is good to understand in what use cases it is a good idea to use IgniteEvents. Audit was mentioned as an example. But it looks like that currently events framework solve _beforehand_ audit when event is triggered before on actual operation. We could document _when_ each type of event is triggered and what _ordering_ guarantees (if any) are there.
> h2. Other
> 1. EVT_CACHE_OBJECT_LOCKED, EVT_CACHE_OBJECT_UNLOCKED provokes questions for MVCC. Should we reuse same event for lock while unlock happens implicitly on transaction commit? Do we need some specific events?
> 2. EVT_CACHE_ENTRY_CREATED, EVT_CACHE_ENTRY_DESTROYED events are almost useless for a user, but it is not obvious immediately.
> 3. {{EventType}} javadoc states that all events are enabled by default, {{IgniteEvents}} javadoc states opposite and a latter seems to be true.
> 4. {{IgniteEvents}} facade encapsulates 2 event processing workflows: event listening and querying events from _event store_. While workflows are related but from the first glance separation between them is not obvious.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)