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
