Vladimir, That's a good question. I confused _ENTRY_ events with those mentioned by you.
Anyway, are you saying that the _ENTRY_ events are workable but have no value or they are not workable any longer with the MVCC? -- Denis On Sat, Sep 22, 2018 at 4:10 AM Vladimir Ozerov <voze...@gridgain.com> wrote: > 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 > > > > > >
