Agreed, Dave. I think that the choice between the two locking strategies would depend rather delicately upon the functionality of the CFC and the architecture in which the it lives. I generally code getter and setter methods for all properties on my CFCs, and code the <cflock>s into them. All CFC self-locks use a UUID property that is populated in the initialization bloc. Since I generate the code for these methods automatically, using some simple regex substitutions, I don't have to hand-tool the locking code. I usually code other CFC methods to <cflock> the CFC using standard snippets that I save in DreamWeaver. One thing that this discussion suggests to me is that the instantiator of such a CFC could set a property on the instance, indicating whether it should self-lock, and the instance could test that property to decide whether to lock itself. The other thing that occurs to me is that a good compromise solution to this issue would be to create something like a J2EE fa�ade. The fa�ade would provide a common interface by which callers can invoke the CFC methods, while transparently deciding whether and how to lock the method invocation. I'll have to think about that a bit more... Steven
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Watts Sent: Tuesday, November 11, 2003 4:23 PM To: '[EMAIL PROTECTED]' Subject: RE: [CFCDev] Application scoped CFC concurrency > 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] ---------------------------------------------------------- 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]
