[
https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999737#comment-12999737
]
Jonathan Ellis commented on CASSANDRA-1311:
-------------------------------------------
bq. Our solution is to make the storage of "dangling" trigger at replicas also
part of log replay. Whenever a replica (slave) node receives a write request,
it will durably log that it has to fire a trigger in case of a failure of the
update coordinator (master). In case this slave node fails, it will come back
up replaying the logs, installing any data item, and also firing triggers.
This sounds really, really fragile. Grafting a pseudo-master onto Cassandra
replication is a bad idea.
> Support (asynchronous) triggers
> -------------------------------
>
> Key: CASSANDRA-1311
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
> Project: Cassandra
> Issue Type: New Feature
> Components: Contrib
> Reporter: Maxim Grinev
> Fix For: 0.8
>
> Attachments: HOWTO-PatchAndRunTriggerExample-update1.txt,
> HOWTO-PatchAndRunTriggerExample.txt, ImplementationDetails-update1.pdf,
> ImplementationDetails.pdf, trunk-967053.txt, trunk-984391-update1.txt,
> trunk-984391-update2.txt
>
>
> Asynchronous triggers is a basic mechanism to implement various use cases of
> asynchronous execution of application code at database side. For example to
> support indexes and materialized views, online analytics, push-based data
> propagation.
> Please find the motivation, triggers description and list of applications:
> http://maxgrinev.com/2010/07/23/extending-cassandra-with-asynchronous-triggers/
> An example of using triggers for indexing:
> http://maxgrinev.com/2010/07/23/managing-indexes-in-cassandra-using-async-triggers/
> Implementation details are attached.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
