[
https://issues.apache.org/jira/browse/CASSANDRA-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215777#comment-13215777
]
Brian ONeill edited comment on CASSANDRA-1311 at 2/24/12 5:58 PM:
------------------------------------------------------------------
FYI -- we've released our Cassandra Trigger functionality, which used the
crack-smoking as a launch point for design.
https://github.com/boneill42/cassandra-triggers
It maintains a column family as a commit log. For each call to .doInsert(), it
writes a log entry into the commit log, first with a status of PREPARING. Then
when the insert completes, it writes status of COMMITTED. Asynchronously, the
commit log is polled and triggers are executed. Upon successful trigger
execution, the log entry is removed from the commit log.
To support distributed processing, each log entry has a host id written along
with it. Hosts process their own log entries first, then also process any log
entries that are older than 5 seconds. So, order of processing is not
guaranteed. This is okay in our situation, because each trigger is idempotent,
and acts directly on the data in the column family (rather than data stored in
the log entry in the commit log)
Right now, this is written as AOP, but we'd be happy to refactor to remove the
AOP and contribute it as a patch. The jar file is available out in the central
repos:
http://mvnrepository.com/artifact/com.hmsonline/hms-cassandra-triggers
was (Author: boneill):
FYI -- we've released our Cassandra Trigger functionality, which used the
crack-smoking as a launch point for design.
https://github.com/boneill42/cassandra-triggers
It maintains a column family as a commit log. For each call to .doInsert(), it
writes a log entry into the commit log, first with a status of PREPARING. Then
when the insert completes, it writes status of COMMITTED. Asynchronously, the
commit log is polled and triggers are executed. Upon successful trigger
execution, the log entry is removed from the commit log.
To support distributed processing, each log entry has a host id written along
with it. Hosts process there own log entries first, then also process any log
entries that are older than 5 seconds. So, order of processing is not
guaranteed. This is okay in our situation, because each trigger is idempotent,
and acts directly on the data in the column family (rather than data stored in
the log entry in the commit log)
Right now, this is written as AOP, but we'd be happy to refactor to remove the
AOP and contribute it as a patch. The jar file is available out in the central
repos:
http://mvnrepository.com/artifact/com.hmsonline/hms-cassandra-triggers
> 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
