userHome is a gateway, among a other things. You might be right about the lock. Depends on how your database implements the transactional locking. You can certainly do a read-only table lock for the check, and then escalate the lock to exclusive for the INSERT and know you've gotten it beaten that way. Or, you just assume it works (which it should), and let the unique key in the database be your ultimate safeguard. Didn't I just say that I never trust keys a couple messages ago? I'm such a liar. ;)
I'm not sure why Sean didn't bring up transactions in that message on the Mach-II list. Maybe he knows something I don't. CFLOCK is definitely an effective way to ensure integrity (assuming all access is via your CFC, a restriction transactions and/or DB locks don't have), but I don't think it's a necessary one. Maybe he'll chime in and explain why I'm wrong, as he is so good at doing? cheers, barneyb On Wed, 3 Nov 2004 12:04:26 -0800, Phil Cruz <[EMAIL PROTECTED]> wrote: > What I meant was "your not doing a CFQUERY in the BO" and you're not, > you're calling the userHome object. Is the userHome object basically > a "gateway" object, i.e. the object that has methods to perform > different queries for users? > > It still seems like you need to CFLOCK this operation somewhere (as > was discussed on the Mach-II list, > http://lists.topica.com/lists/mach-ii-coldfusion/read/message.html?mid=808663514&sort=d&start=500) > > Or am I missing something? > > -Phil > > -- 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]
