ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Ozerov (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-9321) MVCC: support cache events
Date Mon, 11 Mar 2019 08:12:00 GMT

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

Vladimir Ozerov updated IGNITE-9321:
    Labels:   (was: mvcc_monitoring)

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

View raw message