cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Re: Possible design flaw in "Cassandra By Example" blog
Date Wed, 13 Apr 2011 23:51:40 GMT
On Wed, 2011-04-13 at 15:07 -0700, Drew Kutcharian wrote:
> username = 'jericevans'
> password = '**********'
> useruuid = str(uuid())
> columns = {'id': useruuid, 'username': username, 'password': password}
> USER.insert(useruuid, columns)
> USERNAME.insert(username, {'id': useruuid})
> 
> How can I guarantee that USERNAME.insert(username, {'id': useruuid})
> won't overwrite someone else's account. What I mean is how can I
> guarantee that a user's username doesn't already exist in Cassandra? I
> know I can check first, but in a highly concurrent environment,
> there's a possibility that between USER.insert(useruuid, columns) and
> USERNAME.insert(username, {'id': useruuid}) someone else does the same
> USERNAME.insert(username, {'id': useruuid}) and hijack the user's
> account.

Yes, this is a flaw.  You'd need some sort of external coordination to
be sure you could prevent this.

There are probably many such flaws, Twissandra wasn't meant to be a Real
app, it's an aid in teaching the query and data models, and a lot was
glossed over to keep it concise.

> Seems like that USERNAME is something that the author has added since
> it's missing in original Twissandra source code.

Right, since that article was written, the Username column family was
removed, and the User column family is now keyed on username (which
solves the problem of concurrent updates, by making it "last write
wins").

-- 
Eric Evans
eevans@rackspace.com


Mime
View raw message