Instead of trying to solve the generic problem of uniqueness, I would focus on the specific problem.
For eg lets consider your usecase of user registration with email address as key. You can do following: 1. Create CF (Users) where row key is UUID and has user info specific columns. 2. Whenever user registers create a row in this CF with user status flag as waiting for confirmation. 3. Send email to the user's email address with link that contains the UUID (or encrypted UUID) 4. When user clicks on the link, use the UUID (or decrypted UUID) to lookup user 5. If the user exists with given UUID and status as waiting for confirmation then update the status and create a entry in another CF (EmailUUIDIndex) representing email address to UUID mapping. 6. For authentication you can lookup in the index to get UUID and proceed. 7. If a malicious user registers with someone else's email id then he will never be able to confirm and will never have an entry in EmailUUIDIndex. As a additional check if the entry for email id exists in EmailUUIDIndex then the request for registration can be rejected right away. Make sense? -Naren On Fri, Jan 6, 2012 at 4:00 PM, Drew Kutcharian <d...@venarc.com> wrote: > So what are the common RIGHT solutions/tools for this? > > > On Jan 6, 2012, at 2:46 PM, Narendra Sharma wrote: > > >>>It's very surprising that no one seems to have solved such a common use > case. > I would say people have solved it using RIGHT tools for the task. > > > > On Fri, Jan 6, 2012 at 2:35 PM, Drew Kutcharian <d...@venarc.com> wrote: > >> Thanks everyone for the replies. Seems like there is no easy way to >> handle this. It's very surprising that no one seems to have solved such a >> common use case. >> >> -- Drew >> >> On Jan 6, 2012, at 2:11 PM, Bryce Allen wrote: >> >> > That's a good question, and I'm not sure - I'm fairly new to both ZK >> > and Cassandra. I found this wiki page: >> > http://wiki.apache.org/hadoop/ZooKeeper/FailureScenarios >> > and I think the lock recipe still works, even if a stale read happens. >> > Assuming that wiki page is correct. >> > >> > There is still subtlety to locking with ZK though, see (Locks based >> > on ephemeral nodes) from the zk mailing list in October: >> > >> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201110.mbox/thread?0 >> > >> > -Bryce >> > >> > On Fri, 6 Jan 2012 13:36:52 -0800 >> > Drew Kutcharian <d...@venarc.com> wrote: >> >> Bryce, >> >> >> >> I'm not sure about ZooKeeper, but I know if you have a partition >> >> between HazelCast nodes, than the nodes can acquire the same lock >> >> independently in each divided partition. How does ZooKeeper handle >> >> this situation? >> >> >> >> -- Drew >> >> >> >> >> >> On Jan 6, 2012, at 12:48 PM, Bryce Allen wrote: >> >> >> >>> On Fri, 6 Jan 2012 10:03:38 -0800 >> >>> Drew Kutcharian <d...@venarc.com> wrote: >> >>>> 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. >> >>> >> >>> For most applications, if the lock managers is down, you don't >> >>> acquire the lock, so you don't enter the critical section. Rather >> >>> than allowing inconsistency, you become unavailable (at least to >> >>> writes that require a lock). >> >>> >> >>> -Bryce >> >> >> >> > > > -- > Narendra Sharma > Software Engineer > *http://www.aeris.com <http://www.persistentsys.com/>* > *http://narendrasharma.blogspot.com/* > > > > -- Narendra Sharma Software Engineer *http://www.aeris.com <http://www.persistentsys.com>* *http://narendrasharma.blogspot.com/*
