[jira] Issue Comment Edited: (CASSANDRA-132) Support (limited) session level consistency

["Sandeep Tata (JIRA)" <ji...@apache.org>]

    [ 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 2:15 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  I'll add back a check for !hinted node.





      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'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.