It makes great sense. You're a genius!!
On Jan 6, 2012, at 10:43 PM, Narendra Sharma wrote: > 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://narendrasharma.blogspot.com/ >> >> > > > > > -- > Narendra Sharma > Software Engineer > http://www.aeris.com > http://narendrasharma.blogspot.com/ > >
