[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
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 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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9321:
Labels: mvcc_monitoring (was: )
> 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
> Labels: mvcc_monitoring
> 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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9321:
Ignite Flags: (was: Docs Required)
> 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 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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9321:
---
Attachment: EventsProblems.java
> 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.7
>
> 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)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9321:
---
Description:
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.
was:
Currently cache events are not fired for MVCC caches. Need to restore all cache
events.
Starting point: {{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
events should work in the same way on both MVCC and non-MVCC caches.
Events are supposed to fire right away without deferring to transaction end
phase.
> 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.7
>
>
> 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
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-9321:
---
Description:
Currently cache events are not fired for MVCC caches. Need to restore all cache
events.
Starting point: {{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
events should work in the same way on both MVCC and non-MVCC caches.
Events are supposed to fire right away without deferring to transaction end
phase.
was:
Currently cache events are not fired for MVCC caches. Need to restore all cache
events.
Starting point: \{{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
events should work in the same way on both MVCC and non-MVCC caches.
> 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.7
>
>
> Currently cache events are not fired for MVCC caches. Need to restore all
> cache events.
> Starting point: {{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
> events should work in the same way on both MVCC and non-MVCC caches.
> Events are supposed to fire right away without deferring to transaction end
> phase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[
https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-9321:
Description:
Currently cache events are not fired for MVCC caches. Need to restore all cache
events.
Starting point: \{{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
events should work in the same way on both MVCC and non-MVCC caches.
was:Currently cache events are not fired for MVCC caches. Need to restore all
cache events.
> 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.7
>
>
> Currently cache events are not fired for MVCC caches. Need to restore all
> cache events.
> Starting point: \{{org.apache.ignite.events.EventType#EVTS_CACHE}}. All these
> events should work in the same way on both MVCC and non-MVCC caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9321) MVCC: support cache events
[ https://issues.apache.org/jira/browse/IGNITE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9321: Description: Currently cache events are not fired for MVCC caches. Need to restore all cache events. (was: Currently cache events are not fired for MVCC caches. Need to decide what to do with it. Possible options: # Fix events (will require separate data structure and incur possibly serious overhead) # Do not fire events at all # Introduce new events which will not require additional data structures (e.g. "entry_changed" which may be fired even if transaction is rolled back in the end)) > 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.7 > > > Currently cache events are not fired for MVCC caches. Need to restore all > cache events. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
