ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: IgniteEvents for MVCC caches
Date Sat, 22 Sep 2018 14:35:02 GMT
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 <vozerov@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 <dmagda@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 Павлухин Иван <vololo100@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 Павлухин Иван <vololo100@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
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message