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
>

Reply via email to