You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sandeep Tata (JIRA)" <ji...@apache.org> on 2009/05/04 22:26:30 UTC
[jira] Created: (CASSANDRA-132) Support session level consistency
Support 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
Fix For: trunk
Limited session-level consistency: if the client connects to a node and performs operations on rows that are local to that node, we should be able to guarantee read-your-writes consistency. If the session ends because of a failure, and the client has to reconnect, you only provide eventual consistency across the sessions.
(This is a common practical variation of evantual consistency, see: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for context.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711755#action_12711755 ]
Jonathan Ellis commented on CASSANDRA-132:
------------------------------------------
I'm not sure about this part
// Check if local. Don't need to check if this is a hinted
// message because we don't send hints from local to local
We won't send a message hinted for A to node A, but we could send a message to A hinted for B, if B is down. No?
> 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.
[jira] Resolved: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-132.
--------------------------------------
Resolution: Duplicate
Assignee: (was: Sandeep Tata)
superseded by CASSANDRA-876
> Support (limited) session level consistency
> -------------------------------------------
>
> Key: CASSANDRA-132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-132
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: all
> Reporter: Sandeep Tata
> Attachments: CASSANDRA-132-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Tata updated CASSANDRA-132:
-----------------------------------
Attachment: CASSANDRA-132-v3.patch
The debug comment actually says the wrong thing. You're sending to target, not to hint. This patch fixes it too. Use instead of v2.
> 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-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Reopened: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Tata reopened CASSANDRA-132:
------------------------------------
Re-opened after CASSANDRA-399 to move read-your-writes into insertBlocking
> Support (limited) session level consistency
> -------------------------------------------
>
> Key: CASSANDRA-132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-132
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Fix For: 0.4
>
> Attachments: CASSANDRA-132-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Commented: (CASSANDRA-132) Support session level consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705729#action_12705729 ]
Sandeep Tata commented on CASSANDRA-132:
----------------------------------------
Point to note: today, it is possible (even on a single node) that you do an insert followed by a get_column, and you *don't* read the latest value you inserted. The insert is sent as a RowMutationMessage to the endpoints (even if one of them is local) and acked (in the non-blocking variation). It is possible that this message is not received before the next get_column message is processed.
> Support 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
> Fix For: trunk
>
>
> Limited session-level consistency: if the client connects to a node and performs operations on rows that are local to that node, we should be able to guarantee read-your-writes consistency. If the session ends because of a failure, and the client has to reconnect, you only provide eventual consistency across the sessions.
> (This is a common practical variation of evantual consistency, see: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for context.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713230#action_12713230 ]
Jonathan Ellis commented on CASSANDRA-132:
------------------------------------------
committed v3
> 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-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Commented: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "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 commented on CASSANDRA-132:
----------------------------------------
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.
[jira] Issue Comment Edited: (CASSANDRA-132) Support (limited)
session level consistency
Posted by "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 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.
[jira] Issue Comment Edited: (CASSANDRA-132) Support (limited)
session level consistency
Posted by "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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Michael Greene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Greene updated CASSANDRA-132:
-------------------------------------
Component/s: Core
> Support (limited) session level consistency
> -------------------------------------------
>
> Key: CASSANDRA-132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-132
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Fix For: 0.4
>
> Attachments: CASSANDRA-132-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Commented: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713557#action_12713557 ]
Hudson commented on CASSANDRA-132:
----------------------------------
Integrated in Cassandra #89 (See [http://hudson.zones.apache.org/hudson/job/Cassandra/89/])
short circuits sending a message if the mutation's destination is the local node. does not implement hint handling; takes the full message route if hints are involved. patch by Sandeep Tata; reviewed by jbellis for
> 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-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-132:
-------------------------------------
Fix Version/s: (was: 0.5)
> Support (limited) session level consistency
> -------------------------------------------
>
> Key: CASSANDRA-132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-132
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Attachments: CASSANDRA-132-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Tata updated CASSANDRA-132:
-----------------------------------
Attachment: CASSANDRA-132.patch
Attached patch short circuits sending a message if the mutation was intended for the local 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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Tata updated CASSANDRA-132:
-----------------------------------
Attachment: CASSANDRA-132-v2.patch
Local write only if not hinted msg.
> 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-v2.patch, 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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-132:
-------------------------------------
Fix Version/s: (was: 0.4)
0.5
> Support (limited) session level consistency
> -------------------------------------------
>
> Key: CASSANDRA-132
> URL: https://issues.apache.org/jira/browse/CASSANDRA-132
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Fix For: 0.5
>
> Attachments: CASSANDRA-132-v2.patch, CASSANDRA-132-v3.patch, 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.
[jira] Updated: (CASSANDRA-132) Support (limited) session level
consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Tata updated CASSANDRA-132:
-----------------------------------
Description:
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.
was:
Limited session-level consistency: if the client connects to a node and performs operations on rows that are local to that node, we should be able to guarantee read-your-writes consistency. If the session ends because of a failure, and the client has to reconnect, you only provide eventual consistency across the sessions.
(This is a common practical variation of evantual consistency, see: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for context.)
Summary: Support (limited) session level consistency (was: Support session level consistency)
> 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
>
>
> 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.
[jira] Assigned: (CASSANDRA-132) Support session level consistency
Posted by "Sandeep Tata (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandeep Tata reassigned CASSANDRA-132:
--------------------------------------
Assignee: Sandeep Tata
> Support 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
>
>
> Limited session-level consistency: if the client connects to a node and performs operations on rows that are local to that node, we should be able to guarantee read-your-writes consistency. If the session ends because of a failure, and the client has to reconnect, you only provide eventual consistency across the sessions.
> (This is a common practical variation of evantual consistency, see: http://www.allthingsdistributed.com/2008/12/eventually_consistent.html for context.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.