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