[
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
