No, I'm not suggesting locking cfparam tags that don't involve persistent
scope variables, but anything that params or references session, application
or server scopes should.
To clarify the <cffile> comment -- the purpose for using <cflock> around
references to <cffile> and potentially <cfdirectory> is to serialize access
to files in a manner which allows some flexibility and potentially prevent
issues with file-locks from the operating system or IIS causing errors on
the page... As a for instance, if you frequently read and write a specific
file on a site with lots of traffic, it's possible that an IIS file-lock or
operating system file-lock on that file could cause an error on your
coldfusion page during a <cffile> action. By placing a named lock around the
file ( and the absolute file path is an excellent name for the lock since
you already have it _and_ it's unique to the file ), you can allow these
multiple accesses to be "queued" for up to whatever length of time the lock
is specified. The number of accesses to the file "in queue" will fluctuate
and create a "buffer" which prevents errors as a result of the IIS or OS
file locks. For instance:
<cfset myfilepath = "d:\webs\myfile.log">
<cflock name="#myfilepath#" type="exclusive" timeout="30">
<cffile action="append" file="#myfilepath#" output="#mylogentry#">
</cflock>
...
<cflock name="#myfilepath#" type="readonly" timeout="30">
<cffile action="read" file="#myfilepath#" variable="mylogdata">
</cflock>
The same sort of name locking is also recommended as a possible solution to
the use of some older COM objects and the like which need to have serialized
access because running multiple instances of them simultaneously may cause
problems.
Does this make more sense or just make things more muddled?
Isaac
Certified Advanced ColdFusion 5 Developer
www.turnkey.to
954-776-0046
> Ah man! I'm getting confused. I read articles that say you
> should wrap <cffile's in <cflock. Now I don't know what to
> wrap and what not to wrap with <cflock
> I have
> <cfset SESSION.myvar = "something">
> <cfset DirPath = "#Replace (DirPath,'\','/','ALL')#>
> <cfoutput>#SESSION.myVar1#</cfoutput>
> <cfset mode = "1">
> <cfif SESSION.myVar1 GT 0>
> Click...Click...loading gun...
> On Wed, 9 Oct 2002 10:27:16 -0500, Dan Blackman wrote:
>> Certainly you are not suggesting that you lock <cfparam>
>> tags that don't
>> involve session scope?
>>
>> <cfparam name="myVar" ....
>>
>> I could see the need to wrap a lock around a session
>> scoped <cfparam>, but
>> not one that sets a local var...which is what he was
>> asking!
>>
>> Thoughts?
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED]]On
>> Behalf Of S. Isaac Dealey
>> Sent: Wednesday, October 09, 2002 9:21 AM
>> To: [EMAIL PROTECTED]
>> Subject: RE: <cflock & <cfparam
>>
>>
>> > No! Only wrap whats necessary!
>>
>> I've seen poor locking habbits destroy people many times
>> ( and believe me,
>> I'm glad we'll be rid of the need with MX )...
>>
>> An exclusive cflock is _absolutely_ necessary around a
>> <cfparam> in CF 5 and
>> prior. If the value does not exist, then the <cfparam>
>> will attempt to set
>> it -- if you have full-checking turned on in your
>> ColdFusion administrator
>> and have not exclusively locked a <cfparam> tag what you
>> will notice when it
>> attempts to set the variable is that the CF Server
>> catches this and gives
>> you the requested error message indicating that you
>> didn't properly lock the
>> write of your persistent variable. It's possible that you
>> might see some
>> overall performance improvement by not using <cfparam>
>> and instead using a
>> readonly lock to determine if the variable(s) exist and
>> then an exclusive
>> lock only if it is necessary to set those values, i.e.
>>
>> <cflock scope="session" type="readonly" timeout="10">
>> <cfset variables.parameterset =
>> yesnoformat(isdefined("session.mysessionstruct"))>
>> <cfif parameterset>
>> <cfset request.mysessionstruct =
>> duplicate(session.mysessionstruct)>
>> </cfif>
>> </cflock><cfif not parameterset>
>> <cfset request.mysessionstruct = structnew()>
>> ... add additional elements here ...
>> <cflock scope="session" type="exclusive" timeout="10">
>> <cfset session.mysessionstruct =
>> duplicate(request.mysessionstruct)>
>> </cflock>
>> </cfif>
>>
>> The duplicate() function calls are also necessary also to
>> prevent pointers
>> to persistent scope variables, thus preventing you from
>> accidentally
>> allowing what the locking is designed to prevent. If you
>> don't believe me,
>> try this test: turn on full checking of session variables
>> in your CF 5
>> administrator and run this code:
>>
>> <cflock scope="session" type="exclusive" timeout="10">
>> <cfset session.a = structnew()>
>> <cfset session.a.b = "hello world">
>> <cfset request.a = session.a>
>> </cflock>
>>
>> <cfoutput>#request.a.b#</cfoutput>
>>
>> You can take my advice or you can leave it, but if you
>> want stable
>> applications on CF 5 and prior, you must type <cflock
>> _every_ time you type
>> "session", "application" or "server". Doing something
>> like the above with
>> the request scope takes a tiny bit more memory from the
>> server, but fewer
>> processor cycles for the page and significantly less
>> code, just copy all
>> your necessary session, application or server variables
>> in the
>> application.cfm ( or somewhere toward the top fo the page
>> ) and reference
>> the desired variables from the request scope instead of
>> the session scope.
>> It should save you a lot of headache.
>>
>> Also, while it's good to keep your locks small to prevent
>> them taking up
>> enough time to back the queue up and prevent other locks
>> from getting
>> access, you don't need to isolate each individual <cfset>
>> or <cfparam> tag,
>> it's more efficient both in the code and for the server
>> to put a few of them
>> in a single lock than to have a handfull of locks. Just
>> don't go overboard
>> and start putting <cfquery> tags in the lock and the like
>> -- if you need to
>> store a query or other complex variable in a persistent
>> scope, create it
>> first, then duplicate() it into the persistent scope and
>> you should be okay.
>>
>>
>> p.s. there's an excellent article about locking on CF 5
>> and prior at
>> http://www.depressedpress.com
>>
>>
>> hth
>>
>> S. Isaac Dealey
>> Certified Advanced ColdFusion 5 Developer
>>
>> www.turnkey.to
>> 954-776-0046
>>
>> > Use locks in CF 5 only as well...Since
>> > Java
>> > has implicit locking of session vars, CFLOCK has been
>> > deprecated!
>>
>> > HTH
>>
>> > -----Original Message-----
>> > From: [EMAIL PROTECTED]
>> > [mailto:[EMAIL PROTECTED]]On
>> > Behalf Of FlashGuy
>> > Sent: Wednesday, October 09, 2002 8:56 AM
>> > To: FlashMX
>> > Subject: <cflock & <cfparam
>>
>>
>>
>> > I'm setting session variables and using <cflock
>>
>> > <cflock type="exclusive" scope="session" timeout="5">
>> > <cfset SESSION.variable1 = "something1">
>> > </cflock>
>> > <cflock type="exclusive" scope="session" timeout="5">
>> > <cfset SESSION.variable2 = "something2">
>> > </cflock>
>>
>> > I'm also using <cfparam which is being picked up with a
>> > <cfdirectory. Do I
>> > have to wrap the <cfparam with a <cflock also?
>>
>> > <cfparam name="dir" default="d:\">
>>
>>
>>
>>
>> > ---------------------------------------------------
>> > Colonel Nathan R. Jessop
>> > Commanding Officer
>> > Marine Ground Forces
>> > Guatanamo Bay, Cuba
>> > ---------------------------------------------------
>>
>>
>> ---------------------------------------------------------
>> ----------------
>> This email server is running an evaluation copy of the
>> MailShield anti-
>> spam software. Please contact your email administrator if
>> you have any
>> questions about this message. MailShield product info:
>> www.mailshield.com
>>
>> -----------------------------------------------
>> To post, send email to [EMAIL PROTECTED]
>> To subscribe / unsubscribe: http://www.dfwcfug.org
>>
>>
>> ---------------------------------------------------------
>> ----------------
>> This email server is running an evaluation copy of the
>> MailShield anti-
>> spam software. Please contact your email administrator if
>> you have any
>> questions about this message. MailShield product info:
>> www.mailshield.com
>>
>> -----------------------------------------------
>> To post, send email to [EMAIL PROTECTED]
>> To subscribe / unsubscribe: http://www.dfwcfug.org
> ---------------------------------------------------
> Colonel Nathan R. Jessop
> Commanding Officer
> Marine Ground Forces
> Guatanamo Bay, Cuba
> ---------------------------------------------------
> ----------------------------------------------------------
> ---------------
> This email server is running an evaluation copy of the
> MailShield anti-
> spam software. Please contact your email administrator if
> you have any
> questions about this message. MailShield product info:
> www.mailshield.com
> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org
-------------------------------------------------------------------------
This email server is running an evaluation copy of the MailShield anti-
spam software. Please contact your email administrator if you have any
questions about this message. MailShield product info: www.mailshield.com
-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org
