cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandeep Tata (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (CASSANDRA-132) Support (limited) session level consistency
Date Fri, 22 May 2009 00:59:45 GMT

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


Mime
View raw message