[
https://issues.apache.org/jira/browse/CASSANDRA-8287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14207875#comment-14207875
]
Sylvain Lebresne commented on CASSANDRA-8287:
---------------------------------------------
You're right, read repair can screw up isolation. That said, the example above
is actually not affected currently because CQL always read full CQL rows and
thus the step 3) above (you now only read the password) actually don't happen
internally. Granted, it's due to an inefficiency that we want to fix, so it's
still something to consider.
Anyway, that's a problem at the partition level, and I have no clue how to fix
that efficiently. That said, and unless someone has a brilliant idea, I'd be
fine with keeping it a know limitation at the partition level. Keeping it
working at the CQL row level is probably more important however.
> Row Level Isolation is violated by read repair
> ----------------------------------------------
>
> Key: CASSANDRA-8287
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8287
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: sankalp kohli
> Assignee: Sylvain Lebresne
> Priority: Minor
>
> In 1.1, row level isolation was added. As per the blog post
> http://www.datastax.com/dev/blog/row-level-isolation
> "Cassandra guarantees that the changes to login and password are either both
> applied or none are."
> This is not true with background read repair. Consider this as given in the
> blog post.
> You run
> UPDATE Users
> SET login='eric22' AND password='f3g$dq!'
> WHERE key='550e8400-e29b-41d4-a716-446655440000'
> There are 3 machines A,B and C and replication is RF=3
> 1) Machine A did not get this update as it was down and past hint window.
> 2) Machine A comes online.
> 3) You now only read the password.
> 4) password is now read repaired on A.
> SO on machine A, password = f3g$dq! and login is still old
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
