Seth MacPherson said the following on 3/22/2006 1:14 PM: > Allow me to comment on this one... > > Locking an entire query is a really poor choice as well - particularly a > named lock as used in the example. > > Application scoped variables should be locked using > > <CFLOCK SCOPE="APPLICATION"....></CFLOCK> > > And if you need to access an application variable, as in the cfquery > example, you're far better off setting a local variable like so. > > <cflock type="READONLY" scope="APPLICATION" timeout="5"> > <cfset myDsn = application.myDsn /> > </cflock> > > <cfquery name="myQuery" datasource="#myDsn#"> > SELECT Blah > FROM Whah > </cfquery> > > The result is a very quick read and you're not going to cause a race > condition when your query takes a long time to execute. > Locks, locks, locks - the musical fruit. IMHO, people lock too much these days (meaning MX6.1 and MX7). Ask yourself - is this going to create a race condition?
Unless you are going to change the DSN during the lifetime of your application's instance (meaning after you set it when your application starts up) - there is no race condition here. Why are you locking? This is just fine in procedural CF: <cfquery name="myQuery" datasource="#application.myDsn#"> SELECT Blah FROM Whah </cfquery> CFCs are another can of worms. Well, not worms, but it is definitely best practice to pass in your DSN/Timeout/usr/pwd etc into the CFC during init() and store them in the CFC's variable scope. You can do this as individual arguments or you can create a Datasource like CFC to hold stuff and pass that instead as Gerry has suggested. Anyways, rant over ;-) -- Peter J. Farrell :: Maestro Publishing Member Team Mach-II :: Member Team Fusion http://blog.maestropublishing.com Create boilerplate beans and transfer objects for ColdFusion! Fire up a cup of Rooibos! http://rooibos.maestropublishing.com/ ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
