CFLOCK is only required to serialize access to prevent race conditions. For immutable state, no race conditions can arise, so locking is unneeded. Since application.applicationname is immutable, you don't need to lock access to it.
In a more general sense, anything that is only accessed in a read-only and side effect-free fashion doesn't need to be locked. This is the reason that functional languages are so supremely suited to highly concurrent applications. With immutable state and side effect-free operations, the issue of concurrency basically vanishes from the programmer's mind. This purity of environment only works completely in academia, but a very close approximation can be created that is useful for real-world problems. Clojure (a JVM-based Lisp dialect) is an example of this, leveraging Actors to deal with concurrent modification problems without foisting the hassle of locking on the developer. cheers, barneyb On Sun, May 30, 2010 at 2:29 PM, Matthew P. Smith <[email protected]> wrote: > > Does this require a lock? > > I was reading through the CF WACK, and it has an example like so: > <cflock name="#application.applicationname#_whatever" type="exclusive" > timeout="10"> > > does reading the app scope require a lock? Would I nest two locks? Or is > it not required because the application name does not change? > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334129 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
