ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Atri Sharma <atri.j...@gmail.com>
Subject Re: Continuous Query
Date Wed, 29 Apr 2015 11:52:39 GMT
For 1), can we have any issues of state on different nodes i.e.
communicating effectively to all nodes that a query is canceled with
immediate effect?

On Wed, Apr 29, 2015 at 1:53 PM, Yakov Zhdanov <yzhdanov@apache.org> wrote:

> Andrey,
>
> Your points seem very reasonable to me.
>
> 1. Agree that we should have an ability to cancel query from any node at
> any point. It will help if original node leaves and auto unsubscribe is
> "false".
> 2. It is better to use same listener for initial notification. I will think
> on how to refactor this.
> 3. As far as distinguishing initial iteration we can add some attribute to
> entry implementation used in query.
>
> We also had several recent requests to enhance continuous query
> functionality. Give me a couple of days to review code and think everything
> over and I will file tickets to address CQ issues we have now.
>
> Thanks for pointing that out!
>
> --Yakov
>
> 2015-04-28 23:52 GMT+03:00 Kornev, Andrey <andrey.kornev@misys.com>:
>
> > Hello,
> >
> > There are a couple of things wrt Ignite's CQ API and implementation I'd
> > like to bring the community's attention to.
> >
> > First, a CQ instance is a long living resource. Once started it continues
> > to run until explicitly stopped by closing its cursor. If the query
> master
> > node (the one holding the instance of the QueryCursor) crashes and the
> Auto
> > Unsubscribe is off, then it doesn't seem there is any way to stop the CQ
> > save for a complete restart of the grid. Making it possible to obtain the
> > instance of the CQ from any grid node, might improve things.
> >
> > Second, the purpose of the initial query and its usage in the current API
> > is not clear. It makes one wonder what was the original use case the API
> > was designed to address?
> >
> > A couple of things:
> >
> > 1) the implementation doesn't provide a consistent point-in-time snapshot
> > of the cache (no isolation). The cursor may deliver a more recent version
> > of an entry if it got updated by a concurrent transaction. The same entry
> > will also be delivered to the listener as an update event. Please correct
> > me if I'm wrong.
> > 2) the delivery of the initial query results is in no way synchronized
> > with the delivery of the events to the listener.
> >
> > This makes the API prone to race conditions and its correct usage
> > impossible. By "correct usage" I mean the ability to capture point in
> time
> > state of the cache followed by the correctly ordered change data events
> > including the ones that occurred while the initial snapshot was being
> > processed. In database systems it is also known as "materialized view
> > maintenance".
> >
> > It'd be more practical to deliver the initial state to the listener
> > instance rather than to the cursor executing in a different thread. It'd
> > also be necessary to punctuate the end of the initial state delivery and
> > the beginning of the change data events, so that the listener could
> switch
> > from building its initial state to applying incremental updates.
> >
> > I'm curious if any of the above makes any sense?
> >
> > Thanks
> > Andrey
> > "Misys" is the trade name of the Misys group of companies. This email and
> > any attachments have been scanned for known viruses using multiple
> > scanners. This email message is intended for the named recipient only. It
> > may be privileged and/or confidential. If you are not the named recipient
> > of this email please notify us immediately and do not copy it or use it
> for
> > any purpose, nor disclose its contents to any other person. This email
> does
> > not constitute the commencement of legal relations between you and Misys.
> > Please refer to the executed contract between you and the relevant member
> > of the Misys group for the identity of the contracting party with which
> you
> > are dealing.
> >
>



-- 
Regards,

Atri
*l'apprenant*

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