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 Sun, 23 Sep 2018 21:17:00 GMT

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

Vladimir Ozerov updated IGNITE-9321:
------------------------------------
    Fix Version/s:     (was: 2.7)
                   2.8

> 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
>            Assignee: Ivan Pavlukhin
>            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
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
(v7.6.3#76005)

Mime
View raw message