> 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.
By that logic, every CFC that is used as a class template should lock every access to its own data within every method, simply because its instances may someday be stored in a persistent variable. I can understand the appeal of that logic, but it seems to me that the writer of the component will be writing lots of unnecessary code. On the other hand, the programmer using a persistent variable should be aware of the general necessity of handling concurrency, and should know enough about locking to write the appropriate code, whether that code locks access to a simple variable containing only data, or access to a CFC instance. There is certainly room for disagreement on this issue, though. 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]
