Thanks for helping me fully understand why you need the db constraint ;) My last point though is that if you have the constraint you still need to have code to catch the exception and display the appropriate message to the user. With your implementation, the exception would be thrown but presumably caught with a generic error handler that displays "sorry, an unknown error has occured".
So the point is don't think your code doesn't depend on it, rather *know* that it does and plan to handle the exception accordingly. Thanks, Phil On Wed, 3 Nov 2004 17:41:37 -0800, Barney Boisvert <[EMAIL PROTECTED]> wrote: > No, I was totally incorrect. I just got done drawing myself little > pictures about how the transactions would work. If you don't rely on > the unique key, you have to lock somewhere (CFLOCK or DB-based table > locks), as the transaction won't do it. > > I was getting confused with phantom reads. You're not actually > reading the usernames out of the table even though you're checking > them, so they won't be locked as part of the transaction. If you > selected all usernames and verified uniqueness on that result set > (which would be idiotic), then the transaction would do it, assuming > SERIALIZABLE isolation. > > Aside from demonstrating my idiocy, I have made a clear case for > always leaving the DB constraints in (as i said earlier) even though > you *think* your code doesn't depend on them. ; ) > > cheers, > barneyb > > > > On Wed, 3 Nov 2004 17:15:13 -0800, Sean Corfield <[EMAIL PROTECTED]> wrote: > > Two threads could ask for the same user name and both pass your > > uniqueness test (because the user name is not yet in the database) and > > then both store the username -> duplication! > > > > The only atomic way to do this is on the insert, and use a database > > constraint on the username to cause an exception (which you catch and > > translate to something useful, i.e., throw a known validation > > exception). > > > > Or am I missing something subtle in your logic? > > > > > > -- > > > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/blog/ > > I currently have 0 GMail invites for the taking > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
