cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DE VITO Dominique <>
Subject about trigger execution ??? // RE: sending notifications through data replication on remote clusters
Date Mon, 10 Mar 2014 14:50:08 GMT
> You should be able to achieve what you're looking for with a trigger vs. a modification
to the core of Cassandra.

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) ?



On Mon, Mar 10, 2014 at 10:06 AM, DE VITO Dominique <>
> 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.


View raw message