[
https://issues.apache.org/jira/browse/CASSANDRA-5062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626694#comment-13626694
]
Sylvain Lebresne commented on CASSANDRA-5062:
---------------------------------------------
bq. Allocating a lock per row would be madness
Again, I'm not talking about locks here. We can use one true paxos state per
row (which is the alternative I'm suggesting) but still use a 'hashcode % 1024'
number of locks for actually protecting the read/write to the paxos system
table.
What I am suggesting is that we wouldn't keep paxos states in memory however,
i.e. we would always access the system table (and no, I don't necessarily think
this would necessarily destroy performance (some of the reasons are in comment
above). More importantly I think we shouldn't optimize this before having
tested it, since this change the level at which the algorithm apply and that's
not nothing).
bq. we will wait for it, but when it does not reply we will be able to continue
as long as the nodes that did reply constitute a quorum
Alright, didn't so we weren't throwing a timeout in that case. But we'll still
wait rpcTimeout (10 seconds by default!), so I don't think it's much better. In
particular because I really think that ultimately we should respect the overall
write rpc timeout for CAS operation (not suggesting we should do it now, I'm
fine having that being a follow up).
Besides, there is still the 2 other problems I've mentionned.
bq. then we have to add special cases back up to avoid throwing UAE
Granted, but I'm (strongly) convinced that throwing this UAE is wrong in the
first place. Let say that provided checking 'callback.isPromised' is the first
thing we do, which I believe we should, then there is no special casing to do.
> Support CAS
> -----------
>
> Key: CASSANDRA-5062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5062
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
> Fix For: 2.0
>
> Attachments: half-baked commit 1.jpg, half-baked commit 2.jpg,
> half-baked commit 3.jpg
>
>
> "Strong" consistency is not enough to prevent race conditions. The classic
> example is user account creation: we want to ensure usernames are unique, so
> we only want to signal account creation success if nobody else has created
> the account yet. But naive read-then-write allows clients to race and both
> think they have a green light to create.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
