cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "rektide de la fey (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5173) Provide a mechanism to notify listeners when a mutation has occurred (or certain types of mutations have happened)
Date Fri, 25 Jan 2013 21:03:13 GMT


rektide de la fey commented on CASSANDRA-5173:

:facepalm: ^-- is what CASSANDRA-1311 started from, the merge of the cassandra-triggers project.
And indeed, this implementation couples trigger notification with execution of triggers- although
there is a generic ITrigger notification, a decoupled notify only mutation event would be
appreciated, and perhaps a smaller quanta of work.
> Provide a mechanism to notify listeners when a mutation has occurred (or certain types
of mutations have happened)
> ------------------------------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-5173
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: B. Todd Burruss
>            Priority: Minor
> This is related to CASSANDRA-1311 but much less complicated.  I have had the desire in
the past where my application needed to react to mutations on Cassandra that have come from
other DCs.  Essentially using Cassandra as the storage system of record, but also using its
replication as a "bus".
> An example of a straightforward use case is a read through caching system that can be
more intelligent about its data than Cassandra's built in caching - providing better performance.
 One caching system per DC.  The DC to DC replication in Cassandra is nice to keep data in
sync, but the external caching system must know when a mutation comes from another DC and
mark its data as dirty - or do whatever.  Combine these notifications with TTLs on the cache
and you have a fairly robust external caching integration with Cassandra!
> To get this integration, the external cache would register a "listener" (in the same
JVM as Cassandra) for the types of mutations it is interested in, and receive an event when
the conditions are met.  after that it is the job of the listener to do what it needs.
> I created a patch on 1.1.4, but then the business decided on another direction.  If this
is still interesting to the community I can rebase to 1.2 and post the patch, but my use case
has since passed and I will probably not have time to maintain it.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message