incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edward Capriolo <edlinuxg...@gmail.com>
Subject Re: about trigger execution ??? // RE: sending notifications through data replication on remote clusters
Date Mon, 10 Mar 2014 15:46:50 GMT
Just so you know you should probably apply the
[jira] [Commented] (*CASSANDRA*-6790) *Triggers* are broken in trunk
*...*<https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCcQFjAA&url=https%3A%2F%2Fwww.mail-archive.com%2Fcommits%40cassandra.apache.org%2Fmsg80563.html&ei=Hd4dU-7IGOTq0wHT-YHQCw&usg=AFQjCNELJe3hmp_gJWXih91S1CL2f4KLtQ&sig2=xJ5h_7FqX-qZ6iVgXwpr-g&bvm=bv.62578216,d.dmQ>

patch because triggers are currently only called on batch_mutate and will
fail if called on insert.


On Mon, Mar 10, 2014 at 10:50 AM, DE VITO Dominique <
dominique.devito@thalesgroup.com> wrote:

> > You should be able to achieve what you're looking for with a trigger vs.
> a modification to the core of Cassandra.
>
> >
>
> >
> http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-0-prototype-triggers-support
>
>
>
> Well, good point.
>
>
>
> It leads to the question: (a) are triggers executed on all (local+remote)
> coordinator nodes (and then, N DC => N coordinator nodes => N executions of
> the triggers) ?
>
>
>
> (b) Or are triggers executed only on the first coordinator node, and not
> the (next/remote DC) coordinator nodes ?
>
>
>
> My opinion is (b), and in that case, triggers won't do the job.
>
> (b) would make sense, because the first coordinator node would augment
> original row mutations and propagate them towards other coordinator nodes.
> Then, no need to execute triggers on other (remote) coordinator nodes.
>
>
>
> Is there somebody knowing about trigger execution : is it (a) or (b) ?
>
>
>
> Thanks.
>
>
>
> Dominique
>
>
>
>
>
>
>
>
>
> On Mon, Mar 10, 2014 at 10:06 AM, DE VITO Dominique <
> dominique.devito@thalesgroup.com> wrote:
>
> > On 03/10/2014 07:49 AM, DE VITO Dominique wrote:
>
> > > If I update a data on DC1, I just want apps "connected-first" to DC2
>
> > > to be informed when this data is available on DC2 after replication.
>
> >
>
> > If I run a SELECT, I'm going to receive the latest data per the read
> conditions (ONE, TWO, QUORUM), regardless of location of the client
> connection. If using > network aware topology, you'll get the most current
> data in that DC.
>
> >
>
> > > When using Thrift, one way could be to modify CassandraServer class,
>
> > > to send notification to apps according to data coming in into the
>
> > > coordinator node of DC2.
>
> > >
>
> > > Is it "common" (~ the way to do it) ?
>
> > >
>
> > > Is there another way to do so ?
>
> > >
>
> > > When using CQL, is there a precise "src code" place to modify for the
>
> > > same purpose ?
>
> >
>
> > Notifying connected clients about random INSERT or UPDATE statements
> that ran somewhere seems to be far, far outside the scope of storing data.
> Just configure your client to SELECT in the manner that you need.
>
> >
>
> > I may not fully understand your problem and could be simplifying things
> in my head, so feel free to expand.
>
> >
>
> > --
>
> > Michael
>
> First of all, thanks for you answer and your attention.
>
>
>
> I know about SELECT.
>
> The idea, here, is to avoid doing POLLING regularly, as it could be easily
> a performance nightmare.
>
> The idea is to replace POLLING with PUSH, just like in many cases like
> SEDA architecture, or CQRS architecture, or continuous querying with some
> data stores.
>
>
>
> So, following this PUSH idea, it would be nice to inform apps connected to
> a preferred DC that some new data have been replicated, and is now
> "available".
>
>
>
> I hope it's clearer.
>
>
>
> Dominique
>
>
>
>
>

Mime
View raw message