Denis, What is the point of these events, provided that we already has CACHE_PUT and CACHE_REMOVED?
On Sat, Sep 22, 2018 at 1:01 AM Denis Magda <dma...@apache.org> wrote: > Hello Ivan, > > First of all, it looks like that EVT_CACHE_ENTRY_CREATED, > > EVT_CACHE_ENTRY_DESTROYED are legacy came from Ignite 1.x time and have a > > little value nowadays. Does anyone have something against deprecating > them? > > > These events are used in a pure caching or in-memory data grid use cases > where key-value is a primary access pattern. I personally know several > companies who rely on those events. So, we can't discontinue them, not > everyone uses SQL. What's a hurdle of making them working with MVCC? > > -- > Denis > > On Fri, Sep 21, 2018 at 6:44 AM Павлухин Иван <vololo...@gmail.com> wrote: > > > Hi Igniters, > > > > As you might know MVCC was introduced in Apache Ignite. We started > > IgniteEvents support implementation for MVCC caches and faced some > > obstacles. I would like to start a discussion about next steps which > should > > be done to deal with current problems. The main theme is about > > EventType.EVTS_CACHE and key-value API. > > > > First of all, it looks like that EVT_CACHE_ENTRY_CREATED, > > EVT_CACHE_ENTRY_DESTROYED are legacy came from Ignite 1.x time and have a > > little value nowadays. Does anyone have something against deprecating > them? > > > > Second, there could be problems with EVT_CACHE_OBJECT_UNLOCKED event, > > because for MVCC all locks are released on transaction end. And it does > not > > sound good idea to track all locked entries during transaction execution, > > in MVCC we are not keeping entries modified participating in transaction > in > > private working set in memory. One possible solution is deprecation of > > lock, unlock events. Another one is introducing special lock event for > > MVCC, but it will be confusing. Also, I see an option of firing only > > EVT_CACHE_OBJECT_LOCKED. > > > > Last, is different number of events fired for similar scenarios and > > different cache modes. Let's consider "put, remove, put" for the same key > > and different modes. For ATOMIC 2 put and 1 remove event will be fired. > For > > TRANSACTIONAL 1 put will be fired in case of commit and nothing in case > of > > rollback. For MVCC in current vision 2 put will be fired regardless > whether > > transaction was committed and rolled back. Currently I do not see options > > how to overcome it. > > > > Also, I hardly imagine current use cases for cache events. I think that > > understanding them is the best way for developing working solution for > > MVCC. > > > > I need your opinions. > > > > 2018-09-21 12:54 GMT+03:00 Павлухин Иван <vololo...@gmail.com>: > > > > > Hi Igniters, > > > > > > As you might know MVCC was introduced in Apache Ignite. We started > > > IgniteEvents implementation for MVCC caches and faced some obstacles. I > > > would like to start a discussion about next steps which should be done > to > > > deal with current problems. > > > > > > -- > > > Best regards, > > > Ivan Pavlukhin > > > > > > > > > > > -- > > Best regards, > > Ivan Pavlukhin > > >
