Hi, Dave.
It seems to me that it's better for the CFC to handle its own locking.  
Callers don't have to individually code <cflock>s, and don't have to
coordinate how they lock the CFC. This not only eliminates redundant code in
the calling pages and ensures that all accesses to the CFC are locked. It
also eliminates the risk that different pages will erroneously contain
<cflock> syntax that will fail to lock the CFC properly, thru referring to
the wrong scope, wrong name, or wrong type.  
The CFC can and should code a named lock, not a scope lock, using a UUID or
other unique name stored in the CFC as a property. Thus, the CFC doesn't
know or care whether it's in a shared scope, or which one.  It just knows it
may be the site of a concurrency conflict, and thus locks itself against
that eventuality.
Steven Cason
Lockheed Martin Information Technology
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Dave Watts
Sent: Tuesday, November 11, 2003 2:30 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [CFCDev] Application scoped CFC concurrency

> Why would it be better to lock the method call? What's your 
> reasoning here?

Because the object needn't know anything about concurrency, or the fact that
it's in the Application scope, that way.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word '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 word '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]

Reply via email to