[
https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711784#action_12711784
]
Sandeep Tata edited comment on CASSANDRA-132 at 5/21/09 5:59 PM:
-----------------------------------------------------------------
Ah, I guess you're talking about the case where the write arrives at A for a
key intended for B, C, D.
Normally, you'd do A -> B, C, D
If B is down, and you do A -> A (hinted for B) , C, D we'll write a local hint.
This is unlikely, but possible depending on how the replica placement strategy
picks hinted nodes. (I was working under the assumption that the write will go
to one of the owning nodes B, C, D.) I'll add back a check for a hinted message.
was (Author: sandeep_tata):
Ah, I guess you're talking about the case where the write arrives at A for
a key intended for B, C, D.
Normally, you'd do A -> B, C, D
If B is down, and you do A -> A (hinted for B) , C, D we'll write a local hint.
This is unlikely, but possible depending on how the replica placement strategy
picks hinted nodes. (I was working under the assumption that the write will
I'll add back a check for !hinted node.
> Support (limited) session level consistency
> -------------------------------------------
>
> Key: CASSANDRA-132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-132
> Project: Cassandra
> Issue Type: Improvement
> Affects Versions: trunk
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Fix For: trunk
>
> Attachments: CASSANDRA-132.patch
>
>
> Limited session-level consistency: if the client connects to a node and
> performs operations on rows/keys that are local to that node (in that node's
> key range), we should be able to guarantee read-your-writes consistency. If
> the session ends because of a failure, and the client has to reconnect, there
> are no guarantees across the sessions.
> (This is a common practical variation of eventual consistency, see:
> http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for
> context.)
> Supporting this for a "local" sessions is significantly easier than
> supporting session level consistency when the node does not own the data. A
> non-owning node that is reading values from a remote replica will need to
> either do
> a) quorum reads and writes to guarantee session level read-your-writes
> b) pick at least one node to block on and stick to that node as a "master"
> for the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
