[ 
https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216192#comment-13216192
 ] 

Brian ONeill commented on CASSANDRA-1311:
-----------------------------------------

re: more than once processing

Agreed. We have a low write volume right now, which makes it likely that a node 
can process all of its log entries within N seconds. We were also more 
concerned that log entries would sit in the commit log unprocessed in the event 
of a node failure.  Thinking about it a little more, maybe we could have 
written the hash of the row key as a column and query for log entries based on 
the keyspace segment for which the node is repsonsible.

re: passing the row mutation

Also agreed.  In fact, the initial implementation wrote the serialized object, 
but that seemed heavy in the event that large blobs are being written. 
(duplicating the data in the commit log)  Additionally, we wanted to discourage 
developers from acting on the contents of the row mutation (e.g. updating an 
index or view), because the datat contained in the mutation may be out of date. 
(do to the fact that the mutation could have been received out of order)  In 
the second refactoring, we wrote just wrote the column names that were mutated. 
 That seemed sufficient.  In its current state, even that is configurable.  We 
just write the keyspace, column family, row and operation that was performed.  
That way, the commit log is light weight.  It is really just a notificaiton 
that something changed.  The rest is up to the trigger.

                
> Triggers
> --------
>
>                 Key: CASSANDRA-1311
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1311
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Maxim Grinev
>             Fix For: 1.2
>
>         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.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to