> 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.dev...@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
