In CF5 or lower you MUST put a cflock around each and every reference to a shared scope variable whether that variable is being used in a cfset, cfparam, cfif, IsDefined, cfscript, etc.
Preferably, this lock should be a "scope" lock and not a named lock (I believe that CF4.51 introduced the scoped lock; before that you must use a named lock--but be careful!). Also, if you're in cfscript, you'll have to either hop out of cfscript or lock the entire script--since there is no lock funtion for cfscript. As noted earlier, you can always rescope the shared variables to local or request variables before you play with them. And as noted, they are structures so you could use the Duplicate() function. Note: do not use the StructCopy() function. It copies structures by reference, not by value and therefore you would still have to lock the new variable. Note2: beware of race conditions when rescoping shared variables to local and back again. In CFMX, cflock is NOT deprecated. However, you are no longer required to lock shared variables (it doesnt hurt if you have older apps--the performance deficit is very small if you coded the lock efficiently to start with). Im unsure if they deprecated the attributes related to shared variable locking. <cflock> is not deprecated because it is still a highly useful tag when used as a named lock with file or search operations (or other exotic uses that I'm sure exist). Hope this helps to clear things up. Jeremy BTW, Isaac, I liked your article on the Depressed Press Web site (http://www.vboston.com/DepressedPress/Content/ColdFusion/Essays/adlibcoldfu sion/_index.cfm). -----Original Message----- From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 2:41 PM To: [EMAIL PROTECTED] Subject: RE: <cflock & <cfparam 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 ------------------------------------------------------------------------- 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
