On Sun, Mar 14, 2010 at 7:47 PM, David Strauss <da...@fourkitchens.com> wrote: > On 2010-03-14 16:46, Toby DiPasquale wrote: >> My question would be: assuming we're using both quorum reads and >> writes, is it possible that clients A and B could race in the >> following manner: >> >> * A updates its counter >> * B updates its counter >> * A reads the keys to get sum X >> * B reads the keys to get the same sum X >> >> ...thus violating the ever-increasing constraint? > > Yes. You'd need a cluster-wide lock to solve that problem, but then you > may as well use that same cluster-wide locking mechanism to maintain the > count. > > You'll get more interesting responses from this list if you share the > original problem you're trying to solve instead of asking us how to > implement a component of your chosen solution.
I'm actually just trying to build a little URL shortener to use as a demo for an upcoming presentation I'm doing on Cassandra. The counter is to be used as the short key for a new URL submitted to the system: increment the counter and then use the Base-62 encoding of that counter value as the key for that new URL. That's why I'm able to skip some values, but can't have any two clients reading the same value. -- Toby DiPasquale
