Hi guys, Andrey, thanks for pointing out explicit lock/unlock operations. Actually, I think that lock/unlock events are perfectly valid for TRANSACTIONAL caches, so there is a little chance that they could be deprecated. On the other hand mvcc lock/unlock is not related to non-mvcc lock/unlock because we do not support transactions involving caches with different modes. I could imagine that lock/unlock events can be used for debugging purposes. Currently events documentation is quite humble, e.g. for EVT_CACHE_OBJECT_LOCKED event we have javadoc "Built-in event type: object locked.". What object? What does "locked" mean? And "locking" semantics is not slightly different for mvcc and non-mvcc caches (already mentioned unlock on commit). So, another idea which came to my mind is introducing additional event type, say MVCC_LOCKED.
Denis, there are 2 groups of cache events: EVT_CACHE_ENTRY_<...> and EVT_CACHE_OBJECT_<...>. EVT_CACHE_ENTRY_CREATED and EVT_CACHE_ENTRY_DESTROYED are related to on-heap part of cache behavior. Correct me if I am wrong, but now all caches use off-heap storage. And EVT_CACHE_ENTRY_CREATED, EVT_CACHE_ENTRY_DESTROYED are triggered when GridCacheMapEntry object is created as part of an access chain to values stored in the cache. E.g. cache.put invocation causes following sequence of events: CACHE_ENTRY_CREATED, CACHE_OBJECT_PUT, CACHE_ENTRY_DESTROYED. Actually, there are no special problems with supporting CACHE_ENTRY_<...> events for MVCC. And yes, I do not see much user value in them. Also, it seems that I chose a little bit confusing name for the thread. I would like to keep current discussion mainly about key-value API events for MVCC caches. SQL and events is a little bit different topic with number of additional problems. 2018-09-22 17:35 GMT+03:00 Denis Magda <dma...@apache.org>: > 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 > > > > > > > > > > -- Best regards, Ivan Pavlukhin
