[jira] [Commented] (CASSANDRA-1311) Triggers

["Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>]

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

Jonathan Ellis commented on CASSANDRA-1311:
-------------------------------------------

Here's some brainstorming about things to think through to get this into core:

- What guarantees can we make about durability?  Once a mutation is in any replica of the CSCL it can be read for replay, so it should be considered a success in that respect.  But, we can't call it a success for the purposes of the client's request for CL.X yet.  In the extreme case we could have a successful CL write but all replicas down.  One simple approach that does the right thing most of the time would be to perform the same availability checks on the CSCL replicas as for the data replicas.  But, this doesn't address corner cases (nodes going down after the check but before the write), overload situations (nodes being technically up, but timeing out), and also makes the write path more fragile (now we rely on CSCL replicas being up, not just the data nodes).
- How do we handle replay?  We can't simply replay immediately on startup since the CSCL is (probably) on other machines.  Do we wait for one CSCL replica?  All of them?  Do we need to be worried about performance impact of every node in the cluster hammering each other with CSCL requests after a full cluster restart?
- Do we expose the CSCL to non-trigger uses, e.g. atomic batches?
- What API do we provide to trigger authors?  What points in the write path do we allow hooks into, and what do we allow them to do?  (E.g.: cancel the update, modify the RowMutation, create additional RowMutations?  Do we provide the pre-write CF row to the trigger?  If so do we provide a "lightweight" alternative that doesn't force read-before-write?)
- What about implementation?  "Here's an interface, implement it in whatever JVM language you like and give us a class name?"  Appealing, but "now restart your server to get your trigger jar on the classpath" is not.  Neither am I thrilled with the thought of implementing some kind of jar manager that stores triggers in Cassandra itself.  "Triggers are always implemented in javascript?" Maybe a good lowest-common denominator but many developers are not fond of js and Rhino is a bit of a dog.  (Nashorn is due in Java 8, however.)
                
> 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