I'm pretty sure this is incorrect.
If you don't cflock your reads, then your write locks will be useless. An unlocked
read will barrel through even if there is a write lock.
(Unless of course you turn on automatic read-locking)
At 10:01 PM 3/28/01 -0800, Nat Papovich wrote:
>No NEED to cflock only read-onlys to application scope, but it's a darn good
>idea. I'm sure that a heavily-hit site is capable of blowing up if you don't
>do it, but more than likely you'll just get a slow site, as CF attempts to
>do it's rudimentary locking on the application scope (which is an
>undocumented, unconfirmed feature, but it sure seems like that's the case).
>
>application.applicationname is a variable that is created in the application
>scope once the cfapplication tag is executed, and its value is the name of
>the application that you specified in the cfapplication tag. So yes, Hal
>(and you) should lock the IsDefined("application.applicationName"). But then
>again, after reading the previous paragraph, you might not care that much.
>
>So about your last question in regards to cflocking all isDefined() calls,
>it's a good idea. Allaire would say that the definitive answer is to cflock
>them all.
>
>NAT
>
>> -----Original Message-----
>> From: Bob Silverberg [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, March 28, 2001 3:28 PM
>> To: Fusebox
>> Subject: Checking for application.applicationname ( was RE: Nesting
>> circuits: I just don't get it! :()
>>
>>
>> Yeah, that's along the lines of what I was thinking. I have another
>> question, which this made me think of.
>>
>> What's the deal with "application.applicationname"? Is it a variable
>> sitting in the real application scope, or is it a structure in
>> the variables
>> scope that just happens to be called "application"? If the former,
>> shouldn't we be CFLOCKing the IsDefined check, and if the latter,
>> isn't that
>> just really confusing? I wondered this when I read Hal's XFB 101 tutorial
>> but forgot about it. I don't see how it can be a variable in the
>> application scope, as it is being set everytime a page is processed by any
>> user - and it doesn't even know which application it should
>> belong to until
>> after it has been processed. I guess maybe it's neither of the above -
>> maybe it's just a magical "reserved word".
>>
>> While we're on the subject, I've never really been sure whether IsDefined
>> calls to shared scopes need to be CFLOCKED. I always do it because a
>> readonly lock doesn't really impede the application and I figure
>> it's better
>> safe than sorry. On the one hand, you can say that CF doesn't
>> need to read
>> the value, so the lock isn't needed. But on the other hand, it needs to
>> interrogate the scope to determine if the variable exists, and if someone
>> were trying to create that variable at the exact same time that
>> might cause
>> a problem.
>>
>> Anyone have a definitve answer on this?
>>
>> Bob
>>
>> -----Original Message-----
>> From: Mike Craig [mailto:[EMAIL PROTECTED]]
>> Sent: March 28, 2001 5:58 PM
>> To: Fusebox
>> Subject: RE: Nesting circuits: I just don't get it! :(
>>
>>
>> Hal9000...heh...that's cute...I'm surprised somebody hasn't said that yet.
>> I think you are basically right...if you want to "url" directly
>> to a circuit
>> you can, so long as that circuit is designed to stand alone. In
>> his nesting
>> examples, he shows a simple piece of code:
>>
>> <cfinclude template="app_locals.cfm">
>> <cfparam name="attributes.fuseaction" default="home.home">
>>
>> <cfif not IsDefined("application.applicationname")>
>> <cfapplication name="fuseboxworld"
>> applicationtimeout="#CreateTimeSpan(1,0,0,0)#"
>> sessiontimeout="#CreateTimeSpan(0,1,30,0)#"
>> sessionmanagement="Yes"
>> setclientcookies="Yes"
>> clientmanagement="Yes"
>> clientstorage="#request.db.main#">
>> </cfif>
>>
>> <cftry>
>> <cfif Not IsDefined("request.circuits")>
>> <cfinclude template="app_circuits.cfm">
>> </cfif>
>> <cfcatch type="MissingInclude">
>> No Circuits have been defined
>> <cfabort>
>> </cfcatch>
>> </cftry>
>>
>> <cfmodule template="#request.localtags#/Nesting.cfm">
>>
>> .....so that the assumption is that if you are coming into this circuit
>> through another application "home", it will become the "home" at
>> that point.
>> The only thing I changed here is that in the <cfif> statement checking for
>> application.applicationname being defined is that I call app_globals.cfm
>> (which in turn calls other app_ files to set up the display
>> environment, et.
>> al.). This will not be called if an application already exists.
>> Does that
>> sound right to you?
>>
>> Mike Craig
>>
>> -----Original Message-----
>> From: Bob Silverberg [mailto:[EMAIL PROTECTED]]
>> Sent: Wednesday, March 28, 2001 5:16 PM
>> To: Fusebox
>> Subject: RE: Nesting circuits: I just don't get it! :(
>>
>>
>> Now I'm confused. I think all Hal's saying is that you can "point your
>> browser to" different urls as the starting point of your app.
>> That way you
>> can test an individual circuit or a complete app. This isn't to say that
>> you code that directory structure into your fuseaction calls (e.g., form
>> actions, links, cflocations). You still call everything from a single
>> fusebox. As I'm typing this I think I'm figuring it out - as I don't use
>> the official "Hal9000" method. I think the key is that you specify the
>> location of this "master" index in your myGlobals file (e.g., <cfset
>> request.CFROOT="/whatever/">). You then call the master index using this
>> variable. If you use <cfparam> instead of <cfset> then you can
>> set this in
>> each myGlobals file, and whichever one is called first will take affect.
>>
>> So if you call the app from the real root, you'd end up pointing
>> to the real
>> root index.cfm, but if you call the app from a subdirectory (by pointing
>> your browser there), in order to test a circuit app, then the
>> "master" root
>> index.cfm would actually be the one in the circuit app's directory. I
>> believe that circuits.cfm would be the same in each directory. (I
>> don't use
>> circuits.cfm - but I'm beginning to like the idea).
>>
>> Is that right, or am I just more confused now?
>>
>>
>> -----Original Message-----
>> From: Patrick McElhaney [mailto:[EMAIL PROTECTED]]
>> Sent: March 28, 2001 4:44 PM
>> To: Fusebox
>> Subject: RE: Nesting circuits: I just don't get it! :(
>>
>>
>>
>> This is what I'm really interested in (quoted from an earlier post by
>> Hal Helms -
>> http://www.mail-archive.com/[email protected]/msg08051.html):
>>
>> "One nice thing about this is that you can test each circuit by itself
>> (since
>> it can run unchanged as either stand-alone or nested). In test mode, you
>> just point your browser to www.mydomain.com/mySite/users. When you want it
>> as part of the bigger picture, you just point your browser to
>> www.mydomain.com/mySite and users fuseactions will still work fine.
>>
>> The drag and drop would occur if I were to make mySite part of a bigger
>> application, AllSites. Then I would just create another fusebox for
>> AllSites, drag MySite into it, and register mySite in the
>> Circuits.cfm file
>> and everything else would work without being changed."
>>
>> You guys are telling me I can't do that. Is that right?
>>
>> Patrick
>>
>> > -----Original Message-----
>> > From: Mike Craig [mailto:[EMAIL PROTECTED]]
>> > Sent: Wednesday, March 28, 2001 4:27 PM
>> > To: Fusebox
>> > Subject: RE: Nesting circuits: I just don't get it! :(
>> >
>> >
>> > Never might be a strong word, but yes, that is true. This is why the
>> > application root is the only "home" you have and your request.circuits
>> > structure plus the fuseaction help navigate your tree.
>> >
>> > Mike Craig
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
