[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9321:
--------------------------------------
Fix Version/s: (was: 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
> 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)
