I probably should've added that I based my initial findings on a CFMX tech note http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_18235
Which appears to come to the conclusion that although named locks give greater granularity, "It is often simpler to continue using the scope attribute" I'm just really curious as to why a different approach is suggested in the Coding doc dependant on variable scope. Regards Mark -----Original Message----- From: Mark Smyth [mailto:[EMAIL PROTECTED] Sent: 30 March 2005 14:14 To: CF-Talk Subject: RE: Locking shared scope variables Hi Dave Thanks for that. Makes sense about the named locks, but why are scoped locks recommeded for session variables? And "....most read operations do not need to be locked;" now makes sense. It was the exceptions to the rule I couldn't get my head around. Regards Mark -----Original Message----- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: 30 March 2005 14:11 To: CF-Talk Subject: RE: Locking shared scope variables > I'm trying to standardise a locking strategy when setting/reading > shared scope variables > > I've did some research and came up with what I thought was a plan, > exclusive-scoped locks for writing variables and readonly-scoped locks > for reading variables. > > However I crossrefered this against the Macromedia CFMX coding > standards and it has the following: > > "If the shared resource is in server or application scope, you should > use named locks to control access - and choose a name that uniquely > identifies the resource being locked, e.g., use server_varname when > locking an update to server.varname.... > > If the shared resource is in session scope, you should generally use a > scoped lock on session itself." > > AND > > "....most read operations do not need to be locked;" > > This is the first time I have come across this, so two questions come > from this: > > 1. Why named locks for application & server variables and scope for > session? > > 2. Why can read locks be ignored? It's worth pointing out that the MM coding standards probably assume the use of CFMX, and that locking requirements and best practices have changed between CF 5 and CFMX. Named locks allow more granularity than scope locks. You're less likely to have unnecessary lock contention, and you're still able to synchronize access to the variable in question. If you write a variable once, and simply read it afterwards, which is a common thing to do with Application variables, there's very little likelihood that there will be any cases where a write is occurring at the same time as another operation - which of course is what you want to prevent with locking. Multiple concurrent reads are harmless as long as there's no write going on simultaneously. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:200682 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
