Well, the test and set failed could have failed because of a new value replacing the old one since this client read it. Jun is talking about re-reading to get this new value and retrying the "transaction"
On Fri, Apr 3, 2009 at 9:08 AM, Jonathan Ellis (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/CASSANDRA-48?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12695470#action_12695470 > ] > > Jonathan Ellis commented on CASSANDRA-48: > ----------------------------------------- > > The client should not do that. It knows the old version (or it couldn't be > doing test-and-set) and it knows the new version and it knows that not all > replicas were written but some were. Doing a read cannot possibly tell it > anything it doesn't already know. > >> test-and-set >> ------------ >> >> Key: CASSANDRA-48 >> URL: https://issues.apache.org/jira/browse/CASSANDRA-48 >> Project: Cassandra >> Issue Type: Improvement >> Reporter: Jonathan Ellis >> >> Atomic test-and-set insert operation would be nice: "set value to X but only >> if the current value is still Y." This allows a sort of optimistic >> consistency: perform a GET, then perform test-and-set with the value of that >> GET as Y. >> I do not think that this requires strong consistency to be useful. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
