Final two cents -
The race condition I was referring to - though not clearly stated - would be
when you wrap an entire <cfquery>...</cfquery> in a named cflock as
suggested earlier.
*************** Excerpt ******************
(Larry Lyons)
<cflock name="appParamsLock" throwontimeout="yes" timeout="60"
type="exclusive">
<cfset application.DSNParams = structNew()>
<cfset application.DSNParams.DSP = "myDBPassword">
<cfset application.DSNParams.DSN = "myDSN">
<cfset application.DSNParams.DST = "ODBC">
</cflock>
<cfquery name="foobar"
datasource="#application.DSNParams.DSN#"
username="#application.DSNParams.DSU#"
password="#application.DSNParams.DSP"
type="#application.DSNParams.DST#">
select Dunno
from whoCares
where apathy = "true"
</cfquery>
******************************************
(axunderwood)
If you use the Application scope in the query, you're "supposed" to lock the
scope around the query.
******************************************
I'm saying - don't wrap a lock around a query. Ever.
<cflock> <!--- any kind of lock here is a bad idea IMHO --->
<cfquery>
SELECT blah
FROM whoo
</cfquery>
</cflock>
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Peter J. Farrell
Sent: Wednesday, March 22, 2006 11:40 AM
To: [email protected]
Subject: Re: [CFCDev] Storing DSN parameters in a "global" variable
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]
----------------------------------------------------------
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]
