I don't think if you read and write with QUORUM
On Fri, Jan 6, 2012 at 11:01 AM, Drew Kutcharian <d...@venarc.com> wrote: > Yes, my issue is with handling concurrent requests. I'm not sure how your > logic will work with eventual consistency. I'm going to have the same issue > in the "tracker" CF too, no? > > > On Jan 6, 2012, at 10:38 AM, Mohit Anchlia wrote: > >> On Fri, Jan 6, 2012 at 10:03 AM, Drew Kutcharian <d...@venarc.com> wrote: >>> Hi Everyone, >>> >>> What's the best way to reliably have unique constraints like functionality >>> with Cassandra? I have the following (which I think should be very common) >>> use case. >>> >>> User CF >>> Row Key: user email >>> Columns: userId: UUID, etc... >>> >>> UserAttribute1 CF: >>> Row Key: userId (which is the uuid that's mapped to user email) >>> Columns: ... >>> >>> UserAttribute2 CF: >>> Row Key: userId (which is the uuid that's mapped to user email) >>> Columns: ... >>> >>> The issue is we need to guarantee that no two people register with the same >>> email address. In addition, without locking, potentially a malicious user >>> can "hijack" another user's account by registering using the user's email >>> address. >> >> It could be as simple as reading before writing to make sure that >> email doesn't exist. But I think you are looking at how to handle 2 >> concurrent requests for same email? Only way I can think of is: >> >> 1) Create new CF say tracker >> 2) write email and time uuid to CF tracker >> 3) read from CF tracker >> 4) if you find a row other than yours then wait and read again from >> tracker after few ms >> 5) read from USER CF >> 6) write if no rows in USER CF >> 7) delete from tracker >> >> Please note you might have to modify this logic a little bit, but this >> should give you some ideas of how to approach this problem without >> locking. >> >> Regarding hijacking accounts, can you elaborate little more? >>> >>> I know that this can be done using a lock manager such as ZooKeeper or >>> HazelCast, but the issue with using either of them is that if ZooKeeper or >>> HazelCast is down, then you can't be sure about the reliability of the >>> lock. So this potentially, in the very rare instance where the lock manager >>> is down and two users are registering with the same email, can cause major >>> issues. >>> >>> In addition, I know this can be done with other tools such as Redis (use >>> Redis for this use case, and Cassandra for everything else), but I'm >>> interested in hearing if anyone has solved this issue using Cassandra only. >>> >>> Thanks, >>> >>> Drew >