request vs application scope
>Mauricio, this looks good, well done. Thanks. Feel free to download. It's GNU GPL. - mga ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
RE: request vs application scope
Mauricio, this looks good, well done. Kind Regards - Mike Brunt Original Message --- >Of course I'm new to all this myself so I may (and quite probably am) >completely off-base on the "right" way to do this in OO. Hopefully >somebody with some more experience will chime in as well. > >Jim Davis These are all interesting remarks... This HTML editor is actually a CF port from an original PHP version (yes... we pretty much translated line by line and had to work around the looseness of PHP) but I think the "final" result is pretty good. It will be very useful to us. But given the way CF mappings work, and that many users won't have a dedicated Windows CFMX to play around, we want to make it accesible for mortals like us that have to live with what our hosting provider sends our way (heck I am having real trouble making CFFILE work under shared-server Linux hosting... even though that tag is enabled). You can check it out and download it here: http://www.elefectoaxe.com.co/spaw/test.cfm ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
request vs application scope
>Of course I'm new to all this myself so I may (and quite probably am) >completely off-base on the "right" way to do this in OO. Hopefully >somebody with some more experience will chime in as well. > >Jim Davis These are all interesting remarks... This HTML editor is actually a CF port from an original PHP version (yes... we pretty much translated line by line and had to work around the looseness of PHP) but I think the "final" result is pretty good. It will be very useful to us. But given the way CF mappings work, and that many users won't have a dedicated Windows CFMX to play around, we want to make it accesible for mortals like us that have to live with what our hosting provider sends our way (heck I am having real trouble making CFFILE work under shared-server Linux hosting... even though that tag is enabled). You can check it out and download it here: http://www.elefectoaxe.com.co/spaw/test.cfm ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
request vs application scope
>(Perhaps if you show us some code, this will be easier?) LOL... I'm trying to set the SourceForge project but that CVS thing is pretty overwhelming (and I thought I was a techie)... I could send a ZIP file... Mmmm gonna post the ZIP here: http://www.elefectoaxe.com.co/spaw/test.cfm Click the Download link. Feel free to use it... ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
RE: request vs application scope
> -Original Message- > From: Mauricio Giraldo [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 04, 2003 1:56 PM > To: CF-Talk > Subject: request vs application scope > > >>In general, when using CFCs I would recommend creating the variables > >inside the CFCs as instance variables upon invocation rather than "look > >out" of the CFC to external data. > > The idea is to have users generate their own config file without > "touching" the CFCs. How would you recommend this to be done? I'm sorry - I wasn't clear. You can have your "permanent" storage in whatever you like: ini files, the registry, the database, etc. But when you create (instantiate) your CFCs I generally like to copy that data into the CFC for use. In other words the CFC only looks out of itself on construction then caches that data internally. If it's just a config file you want then you have many options: CF can generate and easily edit both XML and INI-style files. You could also store the information in a database. As I said: when you instantiate the CFC you would query/read/parse this source and create internal structures for the data. The CFC would then (in my opinion) feature "getters" and "setters" - methods allowing the properties to be retrieved and manipulated. When you run the "set" methods of object it would update both the in-memory variables and whatever persistent store you're using. You can also complicate this up if it suits your application. You might, for example, only update the in-memory data until a special "Commit" method is called on the object - and then at that point add the new/changed information to the persistent store. Of course I'm new to all this myself so I may (and quite probably am) completely off-base on the "right" way to do this in OO. Hopefully somebody with some more experience will chime in as well. Jim Davis ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Get the mailserver that powers this list at http://www.coolfusion.com
Re: request vs application scope
On Thursday, Sep 4, 2003, at 10:56 US/Pacific, Mauricio Giraldo wrote: >>> In general, when using CFCs I would recommend creating the variables >> inside the CFCs as instance variables upon invocation rather than >> "look >> out" of the CFC to external data. > The idea is to have users generate their own config file without > "touching" the CFCs. How would you recommend this to be done? Use an 'init()' method on the CFC. The user would then call that after creating the CFC and pass in the necessary values. (Perhaps if you show us some code, this will be easier?) Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
request vs application scope
>>In general, when using CFCs I would recommend creating the variables >inside the CFCs as instance variables upon invocation rather than "look >out" of the CFC to external data. The idea is to have users generate their own config file without "touching" the CFCs. How would you recommend this to be done? - mga ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
RE: request vs application scope
> -Original Message- > From: Mauricio Giraldo [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 03, 2003 11:58 PM > To: CF-Talk > Subject: request vs application scope > > Hi > > We are developing this web-based HTML editor: > http://www.elefectoaxe.com.co/spaw/test.cfm > > It uses CFCs and has several configuration variables (default language, > folder to place images into, etc) that are created in a couple of > configuration templates. Right now we handle these configuration variables > in the REQUEST scope. Would it be a better idea to handle them in the > APPLICATION or some other scope? What is the criteria for scope choosing? > This is a SourceForge project and once we upload it you can take a look at > the code. I talk about this quite a bit in my guide to CF variables here: http://www.depressedpress.com/DepressedPress/Content/ColdFusion/Guides/V ariables/Index.cfm In general, when using CFCs I would recommend creating the variables inside the CFCs as instance variables upon invocation rather than "look out" of the CFC to external data. That being said and from the little you've said it seems like the Application makes the most sense. Using the Application scope means that these variables will be created once, and only once, and use up only that much RAM for all users. Using the Request scope would mean that each request would have to create these variables and that the RAM usage would be greater (each request having its own copy of the data). Using the Request scope made a LOT of sense in CF 5 and below as using the Application scope meant a lot of locking. The Request scope was more resource intensive, but allowed for simpler code less likely to fall prey to deadlocks or resource contention. With MX's low-level locking server stability from lack of locking has disappeared. Its now safe to store this kind of information in the Application scope and access it directly. In a sense the Request scope, which in 4.5 and 5.0 became a nice replacement for the Application scope for many things, has now be superseded by the improved Application scope. Jim Davis ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Get the mailserver that powers this list at http://www.coolfusion.com
request vs application scope
Hi We are developing this web-based HTML editor: http://www.elefectoaxe.com.co/spaw/test.cfm It uses CFCs and has several configuration variables (default language, folder to place images into, etc) that are created in a couple of configuration templates. Right now we handle these configuration variables in the REQUEST scope. Would it be a better idea to handle them in the APPLICATION or some other scope? What is the criteria for scope choosing? This is a SourceForge project and once we upload it you can take a look at the code. Regards Mauricio _ Get 10MB of e-mail storage! Sign up for Hotmail Extra Storage. http://join.msn.com/?PAGE=features/es ~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: Request vs application scope
> Isn't it a bit illogical to use request scope for storing
> constants if they can be overwritten?
Since CF doesn't provide anything directly analogous to a constant, it's as
close as you can get. Typically, when used as "constants", request variables
are created in Application.cfm for each page request. They'll have the same
values for each page, since the value will be hard-coded in Application.cfm.
Conceivably, the value could be changed lower in the page, but in all
likelihood, it wouldn't be. For example, if you wanted to reference the
datasource name as a variable, it's going to have the same through the
lifetime of the application - the value isn't going to change as a result of
some action within the application.
On the other hand, if you wanted to have variables which did change over
time, that's a good use of the Application scope. For example, if you wanted
to track how many users were in an application, you might set a variable in
the Application scope, and change it as users entered and left the
application. In this case, you wouldn't be using the variable as a constant
at all.
> I understand that there is no sense in doing isdefined("request.myvar")> as the variable will be
> destroyed no matter what, so you have to always re-initialize
> it. Does that carry more or less penalty than checking for
> existence of an application scope variable with isdefined()?
Again, if the variable is set in Application.cfm in the Request scope, this
won't be an issue - it will always be there! As for whether there's less
overhead in setting a variable in the Request scope on each page request
than setting it once in the Application scope then retrieving that variable
on each page, I honestly don't know. The overhead in either case is likely
to be so low as to be nearly immeasurable, and I'd let ease of use and
readability carry the day - which in my mind would favor the use of the
Request scope for these "constants".
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
yes, but keep in mind what is trying to be accomplished. which is to reduce the access to shared resource variables, thus needing locking. I would prefer to take the hit in setting constants each page request, than worry about the locking around each read and write access, including isDefined. -Original Message- From: stas [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 29, 2001 3:05 PM To: CF-Talk Subject: Re: Request vs application scope Isn't it a bit illogical to use request scope for storing constants if they can be overwritten? I understand that there is no sense in doing as the variable will be destroyed no matter what, so you have to always re-initialize it. Does that carry more or less penalty than checking for existence of an application scope variable with isdefined()? - Original Message - From: "Dave Watts" <[EMAIL PROTECTED]> > Brilliant! So what's the downside? The variables are not > persistent across pages are they? Request variables aren't persistent across pages, as Session, Application and Server variables are. However, you're using them in Application.cfm, so they'll be available on every page. They'll simply be recreated for every page. Since you're using them as constants, there isn't really any downside to using them. Dave Watts, CTO, Fig Leaf Software ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
The primary advantage of using REQUEST scoped variables is the freedom from locking everything, as with APPLICATION and SESSION variables. Steve -Original Message- From: stas [mailto:[EMAIL PROTECTED]] Sent: Sunday, April 29, 2001 4:05 PM To: CF-Talk Subject: Re: Request vs application scope Isn't it a bit illogical to use request scope for storing constants if they can be overwritten? I understand that there is no sense in doing as the variable will be destroyed no matter what, so you have to always re-initialize it. Does that carry more or less penalty than checking for existence of an application scope variable with isdefined()? - Original Message - From: "Dave Watts" <[EMAIL PROTECTED]> > Brilliant! So what's the downside? The variables are not > persistent across pages are they? Request variables aren't persistent across pages, as Session, Application and Server variables are. However, you're using them in Application.cfm, so they'll be available on every page. They'll simply be recreated for every page. Since you're using them as constants, there isn't really any downside to using them. Dave Watts, CTO, Fig Leaf Software ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Request vs application scope
Isn't it a bit illogical to use request scope for storing constants if they can be overwritten? I understand that there is no sense in doing as the variable will be destroyed no matter what, so you have to always re-initialize it. Does that carry more or less penalty than checking for existence of an application scope variable with isdefined()? - Original Message - From: "Dave Watts" <[EMAIL PROTECTED]> > Brilliant! So what's the downside? The variables are not > persistent across pages are they? Request variables aren't persistent across pages, as Session, Application and Server variables are. However, you're using them in Application.cfm, so they'll be available on every page. They'll simply be recreated for every page. Since you're using them as constants, there isn't really any downside to using them. Dave Watts, CTO, Fig Leaf Software ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
no they aren't. If you set a request variable in the application.cfm it's pretty much the same as setting a local variable in terms of persistence... every page will recreate the variable anew. Request variables are different, though, from local variables in that they can be seen inside of custom tags without specifically passing the parameter. One tecnique used often is to set the variable in the application scope in the application.cfm page (using proper locking, of course) and then to copy the variable into the request scope immediately after. This way you save the cost of creating the variable every page load and/or locking a shared scope every time the variable is used... and trade it for the smaller footprint caused by copying the variable from the persistent shared scope to the request scope. |-Original Message- |From: Steve Vosloo [mailto:[EMAIL PROTECTED]] |Sent: Tuesday, May 29, 2001 9:43 AM |To: CF-Talk |Subject: RE: Request vs application scope | | |Brilliant! So what's the downside? The variables are not |persistent across |pages are they? | | | |> -Original Message- |> From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] |> Sent: Tuesday, May 29, 2001 2:56 PM |> To: CF-Talk |> Subject: RE: Request vs application scope |> |> |> Yes thats right. |> |> -Original Message- |> From: Steve Vosloo [mailto:[EMAIL PROTECTED]] |> Sent: 29 May 2001 13:51 |> To: CF-Talk |> Subject: RE: Request vs application scope |> |> |> Thanks. |> |> Can I put any data in there that I want to use across the site? |> And I don't |> have to apply CFLOCKs do I? |> |> |> |> > -Original Message- |> > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] |> > Sent: Tuesday, May 29, 2001 2:32 PM |> > To: CF-Talk |> > Subject: RE: Request vs application scope |> > |> > |> > Absolutely no problem... I do it regularly... |> > |> > -Original Message- |> > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] |> > Sent: 29 May 2001 08:34 |> > To: CF-Talk |> > Subject: Request vs application scope |> > |> > |> > I am using the following line of code in my application.cfm |> > |> > http://127.0.0.1/work/ACME/may2001/website";> > > > > Then elsewhere in the site I refer all links and images to: > > > > #request.HomeDir# > > > > Is this OK to do? I'm trying to avoid using the application > > scope. Are there > > any known of issues with this method? > > > > Thanks. > > Steve > > > > > > > > > > > > Development Manager > > Vardus Internet Solutions (SA) > > > > Tel: (+27) 21 670 9880 > > Fax: (+27) 21 674 4549 > > > > Email: [EMAIL PROTECTED] > > Website: www.vardus.com > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
Depends on a lot of things - complexity of variables, how often they're going to change, how many users you're expecting, how performance-critical the app is, how long it takes to obtain the values that you're going to store (e.g. if you're storing, say, a five-value array, but populating that array takes twenty queries), etc. etc. etc. Both are valid ways of doing it, I just always try to design data structures in terms of what "feels" right, for instance, the Home directory of a site "feels" more like a property of the application, rather than an individual page request, so it goes in the application scope. Besides, if you use app. scope to begin with, you've then got expansibility built in for that horrible day whwn the client says "Great, that's just what I asked for, but what I actually WANT is.." -Original Message- From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 15:37 To: CF-Talk Subject: RE: Request vs application scope But using request vars means the memory is released immediately the request has finished... I would agree if you are planning to store large/complex data (esp query result sets etc) then its probably best to use app scope... But would you consider it best if there are just a few simple vars (maybe 100B)? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 15:07 To: CF-Talk Subject: RE: Request vs application scope That's the downside! Also, they are unique to each request, so memory & processor usage will increase by a set amount for each page request. e.g. APPLICATION scope - First request, you get a CPU performance hit while you set up the app. variables, and 2KB of memory is taken up by the variables. - Subsequent requests will detect the existence of APPLICATION.TestVar, and not bother setting the variables up again. - Total memory usage - 2KB for the application variables, however many page requests are made. REQUEST scope - .. .. .. - Every single request will use the CPU while setting up the variables, and need the 2KB of memory for itself. - If you're in a frameset, that's (say) 3 times the CPU usage and an extra 4KB of memory per client, per hit. - Total memory usage - 2KB * number of frames * number of simultaneous users. If you're using the scope to store queries or other complex objects, or even long strings, you're going to end up with a fairly hefty performance hit. Alistair Davidson Senior Developer Rocom New Media www.rocomx.net -Original Message- From: Steve Vosloo [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 14:43 To: CF-Talk Subject: RE: Request vs application scope Brilliant! So what's the downside? The variables are not persistent across pages are they? > -Original Message- > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 2:56 PM > To: CF-Talk > Subject: RE: Request vs application scope > > > Yes thats right. > > -Original Message- > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > Sent: 29 May 2001 13:51 > To: CF-Talk > Subject: RE: Request vs application scope > > > Thanks. > > Can I put any data in there that I want to use across the site? > And I don't > have to apply CFLOCKs do I? > > > > > -Original Message- > > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 29, 2001 2:32 PM > > To: CF-Talk > > Subject: RE: Request vs application scope > > > > > > Absolutely no problem... I do it regularly... > > > > -Original Message- > > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > > Sent: 29 May 2001 08:34 > > To: CF-Talk > > Subject: Request vs application scope > > > > > > I am using the following line of code in my application.cfm > > > > http://127.0.0.1/work/ACME/may2001/website";> > > > > Then elsewhere in the site I refer all links and images to: > > > > #request.HomeDir# > > > > Is this OK to do? I'm trying to avoid using the application > > scope. Are there > > any known of issues with this method? > > > > Thanks. > > Steve > > > > > > > > > > > > Development Manager > > Vardus Internet Solutions (SA) > > > > Tel: (+27) 21 670 9880 > > Fax: (+27) 21 674 4549 > > > > Email: [EMAIL PROTECTED] > > Website: www.vardus.com > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
> Brilliant! So what's the downside? The variables are not > persistent across pages are they? Request variables aren't persistent across pages, as Session, Application and Server variables are. However, you're using them in Application.cfm, so they'll be available on every page. They'll simply be recreated for every page. Since you're using them as constants, there isn't really any downside to using them. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
But using request vars means the memory is released immediately the request has finished... I would agree if you are planning to store large/complex data (esp query result sets etc) then its probably best to use app scope... But would you consider it best if there are just a few simple vars (maybe 100B)? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 15:07 To: CF-Talk Subject: RE: Request vs application scope That's the downside! Also, they are unique to each request, so memory & processor usage will increase by a set amount for each page request. e.g. APPLICATION scope - First request, you get a CPU performance hit while you set up the app. variables, and 2KB of memory is taken up by the variables. - Subsequent requests will detect the existence of APPLICATION.TestVar, and not bother setting the variables up again. - Total memory usage - 2KB for the application variables, however many page requests are made. REQUEST scope - . . . - Every single request will use the CPU while setting up the variables, and need the 2KB of memory for itself. - If you're in a frameset, that's (say) 3 times the CPU usage and an extra 4KB of memory per client, per hit. - Total memory usage - 2KB * number of frames * number of simultaneous users. If you're using the scope to store queries or other complex objects, or even long strings, you're going to end up with a fairly hefty performance hit. Alistair Davidson Senior Developer Rocom New Media www.rocomx.net -Original Message- From: Steve Vosloo [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 14:43 To: CF-Talk Subject: RE: Request vs application scope Brilliant! So what's the downside? The variables are not persistent across pages are they? > -Original Message- > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 2:56 PM > To: CF-Talk > Subject: RE: Request vs application scope > > > Yes thats right. > > -Original Message- > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > Sent: 29 May 2001 13:51 > To: CF-Talk > Subject: RE: Request vs application scope > > > Thanks. > > Can I put any data in there that I want to use across the site? > And I don't > have to apply CFLOCKs do I? > > > > > -Original Message- > > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 29, 2001 2:32 PM > > To: CF-Talk > > Subject: RE: Request vs application scope > > > > > > Absolutely no problem... I do it regularly... > > > > -Original Message- > > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > > Sent: 29 May 2001 08:34 > > To: CF-Talk > > Subject: Request vs application scope > > > > > > I am using the following line of code in my application.cfm > > > > http://127.0.0.1/work/ACME/may2001/website";> > > > > Then elsewhere in the site I refer all links and images to: > > > > #request.HomeDir# > > > > Is this OK to do? I'm trying to avoid using the application > > scope. Are there > > any known of issues with this method? > > > > Thanks. > > Steve > > > > > > > > > > > > Development Manager > > Vardus Internet Solutions (SA) > > > > Tel: (+27) 21 670 9880 > > Fax: (+27) 21 674 4549 > > > > Email: [EMAIL PROTECTED] > > Website: www.vardus.com > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
That's the downside! Also, they are unique to each request, so memory & processor usage will increase by a set amount for each page request. e.g. APPLICATION scope - First request, you get a CPU performance hit while you set up the app. variables, and 2KB of memory is taken up by the variables. - Subsequent requests will detect the existence of APPLICATION.TestVar, and not bother setting the variables up again. - Total memory usage - 2KB for the application variables, however many page requests are made. REQUEST scope - - Every single request will use the CPU while setting up the variables, and need the 2KB of memory for itself. - If you're in a frameset, that's (say) 3 times the CPU usage and an extra 4KB of memory per client, per hit. - Total memory usage - 2KB * number of frames * number of simultaneous users. If you're using the scope to store queries or other complex objects, or even long strings, you're going to end up with a fairly hefty performance hit. Alistair Davidson Senior Developer Rocom New Media www.rocomx.net -Original Message- From: Steve Vosloo [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 14:43 To: CF-Talk Subject: RE: Request vs application scope Brilliant! So what's the downside? The variables are not persistent across pages are they? > -Original Message- > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 2:56 PM > To: CF-Talk > Subject: RE: Request vs application scope > > > Yes thats right. > > -Original Message- > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > Sent: 29 May 2001 13:51 > To: CF-Talk > Subject: RE: Request vs application scope > > > Thanks. > > Can I put any data in there that I want to use across the site? > And I don't > have to apply CFLOCKs do I? > > > > > -Original Message- > > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 29, 2001 2:32 PM > > To: CF-Talk > > Subject: RE: Request vs application scope > > > > > > Absolutely no problem... I do it regularly... > > > > -Original Message- > > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > > Sent: 29 May 2001 08:34 > > To: CF-Talk > > Subject: Request vs application scope > > > > > > I am using the following line of code in my application.cfm > > > > http://127.0.0.1/work/ACME/may2001/website";> > > > > Then elsewhere in the site I refer all links and images to: > > > > #request.HomeDir# > > > > Is this OK to do? I'm trying to avoid using the application > > scope. Are there > > any known of issues with this method? > > > > Thanks. > > Steve > > > > > > > > > > > > Development Manager > > Vardus Internet Solutions (SA) > > > > Tel: (+27) 21 670 9880 > > Fax: (+27) 21 674 4549 > > > > Email: [EMAIL PROTECTED] > > Website: www.vardus.com > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
> I am using the following line of code in my application.cfm > > http://127.0.0.1/work/ACME/may2001/website";> > > Then elsewhere in the site I refer all links and images to: > > #request.HomeDir# > > Is this OK to do? I'm trying to avoid using the application > scope. Are there any known of issues with this method? There's nothing wrong with that at all. I use this approach very often myself, when creating variables to represent data that doesn't change over the life of the application. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
Brilliant! So what's the downside? The variables are not persistent across pages are they? > -Original Message- > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 2:56 PM > To: CF-Talk > Subject: RE: Request vs application scope > > > Yes thats right. > > -Original Message- > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > Sent: 29 May 2001 13:51 > To: CF-Talk > Subject: RE: Request vs application scope > > > Thanks. > > Can I put any data in there that I want to use across the site? > And I don't > have to apply CFLOCKs do I? > > > > > -Original Message- > > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, May 29, 2001 2:32 PM > > To: CF-Talk > > Subject: RE: Request vs application scope > > > > > > Absolutely no problem... I do it regularly... > > > > -----Original Message- > > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > > Sent: 29 May 2001 08:34 > > To: CF-Talk > > Subject: Request vs application scope > > > > > > I am using the following line of code in my application.cfm > > > > http://127.0.0.1/work/ACME/may2001/website";> > > > > Then elsewhere in the site I refer all links and images to: > > > > #request.HomeDir# > > > > Is this OK to do? I'm trying to avoid using the application > > scope. Are there > > any known of issues with this method? > > > > Thanks. > > Steve > > > > > > > > > > > > Development Manager > > Vardus Internet Solutions (SA) > > > > Tel: (+27) 21 670 9880 > > Fax: (+27) 21 674 4549 > > > > Email: [EMAIL PROTECTED] > > Website: www.vardus.com > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
Yes thats right. -Original Message- From: Steve Vosloo [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 13:51 To: CF-Talk Subject: RE: Request vs application scope Thanks. Can I put any data in there that I want to use across the site? And I don't have to apply CFLOCKs do I? > -Original Message- > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 2:32 PM > To: CF-Talk > Subject: RE: Request vs application scope > > > Absolutely no problem... I do it regularly... > > -Original Message- > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > Sent: 29 May 2001 08:34 > To: CF-Talk > Subject: Request vs application scope > > > I am using the following line of code in my application.cfm > > http://127.0.0.1/work/ACME/may2001/website";> > > Then elsewhere in the site I refer all links and images to: > > #request.HomeDir# > > Is this OK to do? I'm trying to avoid using the application > scope. Are there > any known of issues with this method? > > Thanks. > Steve > > > > > > Development Manager > Vardus Internet Solutions (SA) > > Tel: (+27) 21 670 9880 > Fax: (+27) 21 674 4549 > > Email: [EMAIL PROTECTED] > Website: www.vardus.com > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
Thanks. Can I put any data in there that I want to use across the site? And I don't have to apply CFLOCKs do I? > -Original Message- > From: Daniel Lancelot [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, May 29, 2001 2:32 PM > To: CF-Talk > Subject: RE: Request vs application scope > > > Absolutely no problem... I do it regularly... > > -Original Message- > From: Steve Vosloo [mailto:[EMAIL PROTECTED]] > Sent: 29 May 2001 08:34 > To: CF-Talk > Subject: Request vs application scope > > > I am using the following line of code in my application.cfm > > http://127.0.0.1/work/ACME/may2001/website";> > > Then elsewhere in the site I refer all links and images to: > > #request.HomeDir# > > Is this OK to do? I'm trying to avoid using the application > scope. Are there > any known of issues with this method? > > Thanks. > Steve > > > > > > Development Manager > Vardus Internet Solutions (SA) > > Tel: (+27) 21 670 9880 > Fax: (+27) 21 674 4549 > > Email: [EMAIL PROTECTED] > Website: www.vardus.com > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs application scope
Absolutely no problem... I do it regularly... -Original Message- From: Steve Vosloo [mailto:[EMAIL PROTECTED]] Sent: 29 May 2001 08:34 To: CF-Talk Subject: Request vs application scope I am using the following line of code in my application.cfm http://127.0.0.1/work/ACME/may2001/website";> Then elsewhere in the site I refer all links and images to: #request.HomeDir# Is this OK to do? I'm trying to avoid using the application scope. Are there any known of issues with this method? Thanks. Steve Development Manager Vardus Internet Solutions (SA) Tel: (+27) 21 670 9880 Fax: (+27) 21 674 4549 Email: [EMAIL PROTECTED] Website: www.vardus.com ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Request vs application scope
I am using the following line of code in my application.cfm http://127.0.0.1/work/ACME/may2001/website";> Then elsewhere in the site I refer all links and images to: #request.HomeDir# Is this OK to do? I'm trying to avoid using the application scope. Are there any known of issues with this method? Thanks. Steve Development Manager Vardus Internet Solutions (SA) Tel: (+27) 21 670 9880 Fax: (+27) 21 674 4549 Email: [EMAIL PROTECTED] Website: www.vardus.com ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request vs. Application scope
Application variables are not unique to each request; they do not use the CFID and CFTOKEN, but rather are found based on the NAME of your application as specified in the cfapplication tag. Session variables are stored in RAM on the CF server and are unique to each session. The corruption here comes when multiple people all try to create/read new session variables at the same time and memory is misallocated because CF is allowing thread access to all three at once. Bryan Love ACP Internet Application Developer [EMAIL PROTECTED] -Original Message- From: Jason Lotz [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 19, 2001 4:39 PM To: CF-Talk Subject: Re: Request vs. Application scope Andrew, Thanks for the response. I completely understand what you are saying so I think I misphrased my question. Let's try an example and I'll show you what I mean Let's say you set an Application variable "Application.DSN" under the application named "MyApp". Assuming everything is setup correctly in Application.cfm and , the variable is created and will not time out until "MyApp" expires. Now here is where I get confused. For Application and Session variables, you are supposed to lock them because they are shared by each instance (i.e., browser) that is currently using your app. But, since these variables are supposed to be set seperately for each set of unique tokens, why is looking necessary. For example, if I login as a user and it sets a variable called "Session.ID" to 101, how could this be overwritten or used by another user since it is specified by the unique token pair. Make anymore sense? I know I got away from the original question but this is closer to what I want to know. Thanks, Jason - Original Message - From: "Andrew Tyrone" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, April 19, 2001 3:17 PM Subject: RE: Request vs. Application scope > > -Original Message- > > From: Jason Lotz [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 19, 2001 4:25 PM > > To: CF-Talk > > Subject: Request vs. Application scope > > > > > > I have noticed that I can easily interchange the use of Application and > > Request scoped variables. Both are easily accessible in custom > > tags and are > > only exist for the current http request. So, what are good reasons to use > > one instead of the other? > > > > Jason > > > Application variables are actually good for all requests for the life of the application (set in the cfapplication tag with the applicationtimeout attribute). Request variables are only good for the lifetime of the page that gets called (including any cfinluded files and custom tags, nested or not). Application variables are available to all users and only have to be set once, unless the application times out. In this case, they can be set again, and checked beforehand with IsDefined() so as not to set them when you don't need to. Read up on session management in the ColdFusion documentation. > > > - Andy > > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Request vs. Application scope
Andrew, Thanks for the response. I completely understand what you are saying so I think I misphrased my question. Let's try an example and I'll show you what I mean Let's say you set an Application variable "Application.DSN" under the application named "MyApp". Assuming everything is setup correctly in Application.cfm and , the variable is created and will not time out until "MyApp" expires. Now here is where I get confused. For Application and Session variables, you are supposed to lock them because they are shared by each instance (i.e., browser) that is currently using your app. But, since these variables are supposed to be set seperately for each set of unique tokens, why is looking necessary. For example, if I login as a user and it sets a variable called "Session.ID" to 101, how could this be overwritten or used by another user since it is specified by the unique token pair. Make anymore sense? I know I got away from the original question but this is closer to what I want to know. Thanks, Jason - Original Message - From: "Andrew Tyrone" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, April 19, 2001 3:17 PM Subject: RE: Request vs. Application scope > > -Original Message- > > From: Jason Lotz [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 19, 2001 4:25 PM > > To: CF-Talk > > Subject: Request vs. Application scope > > > > > > I have noticed that I can easily interchange the use of Application and > > Request scoped variables. Both are easily accessible in custom > > tags and are > > only exist for the current http request. So, what are good reasons to use > > one instead of the other? > > > > Jason > > > Application variables are actually good for all requests for the life of the application (set in the cfapplication tag with the applicationtimeout attribute). Request variables are only good for the lifetime of the page that gets called (including any cfinluded files and custom tags, nested or not). Application variables are available to all users and only have to be set once, unless the application times out. In this case, they can be set again, and checked beforehand with IsDefined() so as not to set them when you don't need to. Read up on session management in the ColdFusion documentation. > > > - Andy > > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Request vs. Application scope
You also need to lock your application variables, which add some additional overhead. Todd - Original Message - From: "Andrew Tyrone" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Thursday, April 19, 2001 6:17 PM Subject: RE: Request vs. Application scope > > -Original Message- > > From: Jason Lotz [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, April 19, 2001 4:25 PM > > To: CF-Talk > > Subject: Request vs. Application scope > > > > > > I have noticed that I can easily interchange the use of Application and > > Request scoped variables. Both are easily accessible in custom > > tags and are > > only exist for the current http request. So, what are good reasons to use > > one instead of the other? > > > > Jason > > > Application variables are actually good for all requests for the life of the application (set in the cfapplication tag with the applicationtimeout attribute). Request variables are only good for the lifetime of the page that gets called (including any cfinluded files and custom tags, nested or not). Application variables are available to all users and only have to be set once, unless the application times out. In this case, they can be set again, and checked beforehand with IsDefined() so as not to set them when you don't need to. Read up on session management in the ColdFusion documentation. > > > - Andy > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Request vs. Application scope
I have noticed that I can easily interchange the use of Application and Request scoped variables. Both are easily accessible in custom tags and are only exist for the current http request. So, what are good reasons to use one instead of the other? Jason ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Automatic locking (was: Request VS Application scope)
At 02:41 AM 1/7/01 -0500, Dave Watts wrote: >> [...] There is NO performance penalty over properly used manual read locking.[...] >Are you sure there's no performance penalty? How much testing have you done >on this? Or, are you relying on a test done by someone else? How accurate >was that test? Got me. I am replying on someone else's testing. I have not tested it myself. >> I submit that the "right way" is to use Automatic Read >> locking for those shared scopes that you use in your >> application. Use manual write locking for writes. I challenge >> anyone to give an example where this ISN'T the right thing to >> do from a complexity or performance point of view. > >Here's an example. I write an application, and sell it to someone else. They >deploy it on their server, and for whatever reason, don't enable automatic >read locking. They run the application, and it explodes under heavy load. To some extent this is circular reasoning: Automatic read locking is bad because if I use it someone might disable Automatic read locking, in which case it will not work. Plenty of applications have requirements for their environment. I see no significant difference between the instructions for an application stating "You must set up a datasource for Client variables. Do not use 'registry' Client variables with this application." and "You must turn on Automatic Read Locking for Application scope variables with this application." >Now, you could certainly argue that I could just remind them that they >should have enabled automatic read locking, but if I can avoid a potential >problem with an end-user's configuration by changing how my software works, >without rearchitecting the entire application, it's in my business interest >to do so and avoid the potential problem. > >> And I also agree with Benjamin that automatic EVERYTHING >> locking, implemented properly inside the Cold Fusion server, >> would be the true "right way" to do it. > >I agree with this as well, but I'm willing to accept the possibility that >it's not as easy as we might think it is. In any case, we've got to write >code that works on the servers that we have now. > >Dave Watts, CTO, Fig Leaf Software >http://www.figleaf.com/ >voice: (202) 797-5496 >fax: (202) 797-5444 --- Peter Theobald, Chief Technology Officer LiquidStreaming http://www.liquidstreaming.com [EMAIL PROTECTED] Phone 1.212.545.1232 x204 Fax 1.212.545.0938 To put this contact information into your Palm device, click here: http://www.coola.com/cgi-bin/addinfo.cgi?pid=15803&rid=972879910&type=A ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Automatic locking (was: Request VS Application scope)
> This is also the reason I have been ranting about Automatic > Read locking on this list lately. It works. There is NO > performance penalty over properly used manual read locking. I > am sure the ONLY reason it isn't at least the default if not > the ONLY choice is simply a legacy from older versions of Cold > Fusion. Are you sure there's no performance penalty? How much testing have you done on this? Or, are you relying on a test done by someone else? How accurate was that test? > I submit that the "right way" is to use Automatic Read > locking for those shared scopes that you use in your > application. Use manual write locking for writes. I challenge > anyone to give an example where this ISN'T the right thing to > do from a complexity or performance point of view. Here's an example. I write an application, and sell it to someone else. They deploy it on their server, and for whatever reason, don't enable automatic read locking. They run the application, and it explodes under heavy load. Now, you could certainly argue that I could just remind them that they should have enabled automatic read locking, but if I can avoid a potential problem with an end-user's configuration by changing how my software works, without rearchitecting the entire application, it's in my business interest to do so and avoid the potential problem. > And I also agree with Benjamin that automatic EVERYTHING > locking, implemented properly inside the Cold Fusion server, > would be the true "right way" to do it. I agree with this as well, but I'm willing to accept the possibility that it's not as easy as we might think it is. In any case, we've got to write code that works on the servers that we have now. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request VS Application scope
Here Here!! Finally someone seems to understand/agree with my frustration on this point. The way Cold Fusion handles locking is just DUMB. It is ASKING for application instability, which in the long run will ruin the reputation of Cold Fusion as a web development environment. It is especially bad when you consider that much of the focus of Cold Fusion is to allow less experienced programmers to produce excellent complex web sites very rapidly. This is also the reason I have been ranting about Automatic Read locking on this list lately. It works. There is NO performance penalty over properly used manual read locking. I am sure the ONLY reason it isn't at least the default if not the ONLY choice is simply a legacy from older versions of Cold Fusion. I submit that the "right way" is to use Automatic Read locking for those shared scopes that you use in your application. Use manual write locking for writes. I challenge anyone to give an example where this ISN'T the right thing to do from a complexity or performance point of view. And I also agree with Benjamin that automatic EVERYTHING locking, implemented properly inside the Cold Fusion server, would be the true "right way" to do it. At 05:47 PM 1/2/01 -0500, Benjamin S. Rogers wrote: >> The reason why locking is visible to the developer is because it is much >> more efficient if the person writing the code, who knows how the >application >> should work, decides where to lock and more importantly what type of lock >to >> use. If the ColdFusion server had to decide whether to use a ReadOnly or >> Exclusive lock, there would be enormous performance degradation. It is >much >> more efficient if the programmer tells the server which type of lock to >use. >> It's the same thing as telling the server which scope a variable is in, >> instead of having the CF Server go through the variable scope hierarchy. > >This is incorrect. ColdFusion should handle all locking internally except >transactional locking. I have yet to see a reason (aside from developer >laziness) that an exclusive lock should not occur when a session variable is >being written or a read lock should occur when a session variable is being >read. > >A much better analogy is that of the RDBMSs we all know and love. In those >environments, locking is handled by the application. If the developer needs >to combine a series of commands into a single lock (a.k.a. a transaction), >then that option is available to the developer. > >Unlocked commands can cause dirty data at best and system instability at >worst. I don't see why this would be the default behavior of ColdFusion as >opposed to locking all commands except where the developer chooses to >override this to ensure transactional integrity. > >I've argued this point before, both on this list and elsewhere. I maintain >that the issues with are the result of asking a single threaded >application server to behave as a multithreaded application server. Rather >than rewrite the portions of the ColdFusion server that did not behave >properly in a multithreaded environment, they have shuffled off this >responsibility to ColdFusion developers. > >Benjamin S. Rogers >Web Developer, c4.net >voice: (508) 240-0051 >fax: (508) 240-0057 > > > ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request VS Application scope
Here Here!! Finally someone seems to understand/agree with my frustration on this point. The way Cold Fusion handles locking is just DUMB. It is ASKING for application instability, which in the long run will ruin the reputation of Cold Fusion as a web development environment. It is especially bad when you consider that much of the focus of Cold Fusion is to allow less experienced programmers to produce excellent complex web sites very rapidly. This is also the reason I have been ranting about Automatic Read locking on this list lately. It works. There is NO performance penalty over properly used manual read locking. I am sure the ONLY reason it isn't at least the default if not the ONLY choice is simply a legacy from older versions of Cold Fusion. I submit that the "right way" is to use Automatic Read locking for those shared scopes that you use in your application. Use manual write locking for writes. I challenge anyone to give an example where this ISN'T the right thing to do from a complexity or performance point of view. And I also agree with Benjamin that automatic EVERYTHING locking, implemented properly inside the Cold Fusion server, would be the true "right way" to do it. At 05:47 PM 1/2/01 -0500, Benjamin S. Rogers wrote: > The reason why locking is visible to the developer is because it is much > more efficient if the person writing the code, who knows how the application > should work, decides where to lock and more importantly what type of lock to > use. If the ColdFusion server had to decide whether to use a ReadOnly or > Exclusive lock, there would be enormous performance degradation. It is much > more efficient if the programmer tells the server which type of lock to use. > It's the same thing as telling the server which scope a variable is in, > instead of having the CF Server go through the variable scope hierarchy. This is incorrect. ColdFusion should handle all locking internally except transactional locking. I have yet to see a reason (aside from developer laziness) that an exclusive lock should not occur when a session variable is being written or a read lock should occur when a session variable is being read. A much better analogy is that of the RDBMSs we all know and love. In those environments, locking is handled by the application. If the developer needs to combine a series of commands into a single lock (a.k.a. a transaction), then that option is available to the developer. Unlocked commands can cause dirty data at best and system instability at worst. I don't see why this would be the default behavior of ColdFusion as opposed to locking all commands except where the developer chooses to override this to ensure transactional integrity. I've argued this point before, both on this list and elsewhere. I maintain that the issues withare the result of asking a single threaded application server to behave as a multithreaded application server. Rather than rewrite the portions of the ColdFusion server that did not behave properly in a multithreaded environment, they have shuffled off this responsibility to ColdFusion developers. Benjamin S. Rogers Web Developer, c4.net voice: (508) 240-0051 fax: (508) 240-0057 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: Request VS Application scope
> The reason why locking is visible to the developer is because it is much > more efficient if the person writing the code, who knows how the application > should work, decides where to lock and more importantly what type of lock to > use. If the ColdFusion server had to decide whether to use a ReadOnly or > Exclusive lock, there would be enormous performance degradation. It is much > more efficient if the programmer tells the server which type of lock to use. > It's the same thing as telling the server which scope a variable is in, > instead of having the CF Server go through the variable scope hierarchy. This is incorrect. ColdFusion should handle all locking internally except transactional locking. I have yet to see a reason (aside from developer laziness) that an exclusive lock should not occur when a session variable is being written or a read lock should occur when a session variable is being read. A much better analogy is that of the RDBMSs we all know and love. In those environments, locking is handled by the application. If the developer needs to combine a series of commands into a single lock (a.k.a. a transaction), then that option is available to the developer. Unlocked commands can cause dirty data at best and system instability at worst. I don't see why this would be the default behavior of ColdFusion as opposed to locking all commands except where the developer chooses to override this to ensure transactional integrity. I've argued this point before, both on this list and elsewhere. I maintain that the issues with are the result of asking a single threaded application server to behave as a multithreaded application server. Rather than rewrite the portions of the ColdFusion server that did not behave properly in a multithreaded environment, they have shuffled off this responsibility to ColdFusion developers. Benjamin S. Rogers Web Developer, c4.net voice: (508) 240-0051 fax: (508) 240-0057 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Request VS Application scope
> In the real world ColdFusion doesnt handle its persistent > variables so well. There is the factor of locking and > many things that should not be visible to the developer > (in a language like CF... which are). The reason why locking is visible to the developer is because it is much more efficient if the person writing the code, who knows how the application should work, decides where to lock and more importantly what type of lock to use. If the ColdFusion server had to decide whether to use a ReadOnly or Exclusive lock, there would be enormous performance degradation. It is much more efficient if the programmer tells the server which type of lock to use. It's the same thing as telling the server which scope a variable is in, instead of having the CF Server go through the variable scope hierarchy. > The tradeoff is you are dealing with a > non persistent scope, so request scope is easier > but implemented properly application scope should > and CAN be much faster Not to sound cynical, but have you done tests? I would like to see how much of a performance increase you get from locking application variables for read only every page request as opposed to setting request variables each page request. That is originally what this thread was asking about, if I understand the original authors thread correctly. --Greg - Original Message - From: "Jeremy Allen" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Tuesday, January 02, 2001 4:35 PM Subject: RE: Request VS Application scope > One of the points to using application variables is the > fact that they are persistent. The entire scope is a > shared memory scope which means that your variables persist > which means you dont have to continually set them every > time. > > Request scope does not persist beyond one template call.. > > So the difference in performance is, setting variables > you need each time, or simply reading variables back > out of a scope that persists. > > Of course that is in ideal world.. > > In the real world ColdFusion doesnt handle its persistent > variables so well. There is the factor of locking and > many things that should not be visible to the developer > (in a language like CF... which are). Thus it becomes > a bit easier to deal with if you dont have to worry > locking. The tradeoff is you are dealing with a > non persistent scope, so request scope is easier > but implemented properly application scope should > and CAN be much faster... And typically if you are > doing more reading than writing this is still > true, it is just cumbersome to lock everything. > > Jeremy Allen > elliptIQ Inc. > > >-Original Message- > >From: Greg Wolfinger [mailto:[EMAIL PROTECTED]] > >Sent: Tuesday, January 02, 2001 4:21 PM > >To: CF-Talk > >Subject: Re: Request VS Application scope > > > > > >> So it appears your choice is to properly lock access to shared variables > >and take the slight performance hit > >> using either automatic locking or manual locking, or do not properly lock > >access to shared variables and have > >> an unstable server > > > >If I understand your response correctly (which I may not have), here is my > >reply: > > > >I wasn't saying that you shouldn't properly lock you application variables. > >You always should lock those variables. However, with the request > >scope you > >do not have to lock your variables therefore you gain performance using the > >request scope. Of course setting your constants for every user with the > >request scope also degrades some performance, but I think that the tradeoff > >makes it worth using the Reqeust scope. > > > >--Greg > >- Original Message - > >From: "Peter Theobald" <[EMAIL PROTECTED]> > >To: "CF-Talk" <[EMAIL PROTECTED]> > >Sent: Tuesday, January 02, 2001 3:38 PM > >Subject: Re: Request VS Application scope > > > > > >> But as a recent thread discussed, proper coding requires that you should > >always lock every access to an Application variable, in which case > >automatic > >read locking on Application scope variables does not degrade > >performance any > >more than manual read locking of every read of an Application scope > >variable. So it appears your choice is to properly lock access to shared > >variables and take the slight performance hit using either > >automatic locking > >or manual locking, or do not properly lock access to shared variables and > >have an unstable server. > >> > >> Richard Kern wrote: > >> [...]Summary of lock testing on CF Serv
RE: Request VS Application scope
One of the points to using application variables is the fact that they are persistent. The entire scope is a shared memory scope which means that your variables persist which means you dont have to continually set them every time. Request scope does not persist beyond one template call.. So the difference in performance is, setting variables you need each time, or simply reading variables back out of a scope that persists. Of course that is in ideal world.. In the real world ColdFusion doesnt handle its persistent variables so well. There is the factor of locking and many things that should not be visible to the developer (in a language like CF... which are). Thus it becomes a bit easier to deal with if you dont have to worry locking. The tradeoff is you are dealing with a non persistent scope, so request scope is easier but implemented properly application scope should and CAN be much faster... And typically if you are doing more reading than writing this is still true, it is just cumbersome to lock everything. Jeremy Allen elliptIQ Inc. >-Original Message- >From: Greg Wolfinger [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, January 02, 2001 4:21 PM >To: CF-Talk >Subject: Re: Request VS Application scope > > >> So it appears your choice is to properly lock access to shared variables >and take the slight performance hit >> using either automatic locking or manual locking, or do not properly lock >access to shared variables and have >> an unstable server > >If I understand your response correctly (which I may not have), here is my >reply: > >I wasn't saying that you shouldn't properly lock you application variables. >You always should lock those variables. However, with the request >scope you >do not have to lock your variables therefore you gain performance using the >request scope. Of course setting your constants for every user with the >request scope also degrades some performance, but I think that the tradeoff >makes it worth using the Reqeust scope. > >--Greg >- Original Message - >From: "Peter Theobald" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Tuesday, January 02, 2001 3:38 PM >Subject: Re: Request VS Application scope > > >> But as a recent thread discussed, proper coding requires that you should >always lock every access to an Application variable, in which case >automatic >read locking on Application scope variables does not degrade >performance any >more than manual read locking of every read of an Application scope >variable. So it appears your choice is to properly lock access to shared >variables and take the slight performance hit using either >automatic locking >or manual locking, or do not properly lock access to shared variables and >have an unstable server. >> >> Richard Kern wrote: >> [...]Summary of lock testing on CF Server >> [...]First the method of locking whether on the server or actual >page does >not >> significantly affect the application performance.[...] >> >> >> At 03:38 PM 1/2/01 -0500, Greg Wolfinger wrote: >> >To my understanding using automatic read locking degrades the >performance >of >> >a server greatly. Also, any performance degrade with using the Request >> >scope won't make too much of a noticable difference. This is only my >> >understanding, but I'm not positive. So as far as I am >concerned the use >of >> >the Request scope is the way to go. >> > >> >--Greg >> >- Original Message - >> >From: "Bryan Love" <[EMAIL PROTECTED]> >> >To: "CF-Talk" <[EMAIL PROTECTED]> >> >Sent: Tuesday, January 02, 2001 2:43 PM >> >Subject: Request VS Application scope >> > >> > >> >> Here's an interesting question: >> >> >> >> We all know that setting global variables in the request scope is >faster >> >and >> >> more thread-safe than using the Application scope, but does >that remain >> >true >> >> as we scale? >> >> >> >> >> >> Environment: 50 request variables are set in application.cfm (so they >are >> >> set every time a page is called) OR >> >>50 application variables are set one time. >> >> >> >> Scenario 1: >> >> One person hits the site. One of the following happens depending on >> >> how you've written the application: >> >> a. 50 request variables are set and five are read >> >> b. 5 application variables are read >> >> >> >> Scenario 2: >> >> 5
Re: Request VS Application scope
> So it appears your choice is to properly lock access to shared variables and take the slight performance hit > using either automatic locking or manual locking, or do not properly lock access to shared variables and have > an unstable server If I understand your response correctly (which I may not have), here is my reply: I wasn't saying that you shouldn't properly lock you application variables. You always should lock those variables. However, with the request scope you do not have to lock your variables therefore you gain performance using the request scope. Of course setting your constants for every user with the request scope also degrades some performance, but I think that the tradeoff makes it worth using the Reqeust scope. --Greg - Original Message - From: "Peter Theobald" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Tuesday, January 02, 2001 3:38 PM Subject: Re: Request VS Application scope > But as a recent thread discussed, proper coding requires that you should always lock every access to an Application variable, in which case automatic read locking on Application scope variables does not degrade performance any more than manual read locking of every read of an Application scope variable. So it appears your choice is to properly lock access to shared variables and take the slight performance hit using either automatic locking or manual locking, or do not properly lock access to shared variables and have an unstable server. > > Richard Kern wrote: > [...]Summary of lock testing on CF Server > [...]First the method of locking whether on the server or actual page does not > significantly affect the application performance.[...] > > > At 03:38 PM 1/2/01 -0500, Greg Wolfinger wrote: > >To my understanding using automatic read locking degrades the performance of > >a server greatly. Also, any performance degrade with using the Request > >scope won't make too much of a noticable difference. This is only my > >understanding, but I'm not positive. So as far as I am concerned the use of > >the Request scope is the way to go. > > > >--Greg > >- Original Message - > >From: "Bryan Love" <[EMAIL PROTECTED]> > >To: "CF-Talk" <[EMAIL PROTECTED]> > >Sent: Tuesday, January 02, 2001 2:43 PM > >Subject: Request VS Application scope > > > > > >> Here's an interesting question: > >> > >> We all know that setting global variables in the request scope is faster > >and > >> more thread-safe than using the Application scope, but does that remain > >true > >> as we scale? > >> > >> > >> Environment: 50 request variables are set in application.cfm (so they are > >> set every time a page is called) OR > >>50 application variables are set one time. > >> > >> Scenario 1: > >> One person hits the site. One of the following happens depending on > >> how you've written the application: > >> a. 50 request variables are set and five are read > >> b. 5 application variables are read > >> > >> Scenario 2: > >> 5,000 people hit the site at once (i.e. Amazon opens sale of PS2 to > >> public). One of the following happens: > >> a. 250,000 request variables are set and 25,000 are read > >> b. 25,000 application variables are read with automatic read > >> locking set to ON in the CF admin > >> > >> > >> I would very much like to hear some feedback on this if anyone wants to > >> hypothesize about the results. > >> > >> Bryan Love ACP > >> [EMAIL PROTECTED] > >> > >> > >> > > > ~ Paid Sponsorship ~ Get Your Own Dedicated Win2K Server! Instant Activation for $99/month w/Free Setup from SoloServer PIII600 / 128 MB RAM / 20 GB HD / 24/7/365 Tech Support Visit SoloServer, https://secure.irides.com/clientsetup.cfm. Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Request VS Application scope
But as a recent thread discussed, proper coding requires that you should always lock every access to an Application variable, in which case automatic read locking on Application scope variables does not degrade performance any more than manual read locking of every read of an Application scope variable. So it appears your choice is to properly lock access to shared variables and take the slight performance hit using either automatic locking or manual locking, or do not properly lock access to shared variables and have an unstable server. Richard Kern wrote: [...]Summary of lock testing on CF Server [...]First the method of locking whether on the server or actual page does not significantly affect the application performance.[...] At 03:38 PM 1/2/01 -0500, Greg Wolfinger wrote: >To my understanding using automatic read locking degrades the performance of >a server greatly. Also, any performance degrade with using the Request >scope won't make too much of a noticable difference. This is only my >understanding, but I'm not positive. So as far as I am concerned the use of >the Request scope is the way to go. > >--Greg >- Original Message - >From: "Bryan Love" <[EMAIL PROTECTED]> >To: "CF-Talk" <[EMAIL PROTECTED]> >Sent: Tuesday, January 02, 2001 2:43 PM >Subject: Request VS Application scope > > >> Here's an interesting question: >> >> We all know that setting global variables in the request scope is faster >and >> more thread-safe than using the Application scope, but does that remain >true >> as we scale? >> >> >> Environment: 50 request variables are set in application.cfm (so they are >> set every time a page is called) OR >>50 application variables are set one time. >> >> Scenario 1: >> One person hits the site. One of the following happens depending on >> how you've written the application: >> a. 50 request variables are set and five are read >> b. 5 application variables are read >> >> Scenario 2: >> 5,000 people hit the site at once (i.e. Amazon opens sale of PS2 to >> public). One of the following happens: >> a. 250,000 request variables are set and 25,000 are read >> b. 25,000 application variables are read with automatic read >> locking set to ON in the CF admin >> >> >> I would very much like to hear some feedback on this if anyone wants to >> hypothesize about the results. >> >> Bryan Love ACP >> [EMAIL PROTECTED] >> >> >> > ~ Paid Sponsorship ~ Get Your Own Dedicated Win2K Server! Instant Activation for $99/month w/Free Setup from SoloServer PIII600 / 128 MB RAM / 20 GB HD / 24/7/365 Tech Support Visit SoloServer, https://secure.irides.com/clientsetup.cfm. Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: Request VS Application scope
To my understanding using automatic read locking degrades the performance of a server greatly. Also, any performance degrade with using the Request scope won't make too much of a noticable difference. This is only my understanding, but I'm not positive. So as far as I am concerned the use of the Request scope is the way to go. --Greg - Original Message - From: "Bryan Love" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Tuesday, January 02, 2001 2:43 PM Subject: Request VS Application scope > Here's an interesting question: > > We all know that setting global variables in the request scope is faster and > more thread-safe than using the Application scope, but does that remain true > as we scale? > > > Environment: 50 request variables are set in application.cfm (so they are > set every time a page is called) OR >50 application variables are set one time. > > Scenario 1: > One person hits the site. One of the following happens depending on > how you've written the application: > a. 50 request variables are set and five are read > b. 5 application variables are read > > Scenario 2: > 5,000 people hit the site at once (i.e. Amazon opens sale of PS2 to > public). One of the following happens: > a. 250,000 request variables are set and 25,000 are read > b. 25,000 application variables are read with automatic read > locking set to ON in the CF admin > > > I would very much like to hear some feedback on this if anyone wants to > hypothesize about the results. > > Bryan Love ACP > [EMAIL PROTECTED] > > > ~ Paid Sponsorship ~ Get Your Own Dedicated Win2K Server! Instant Activation for $99/month w/Free Setup from SoloServer PIII600 / 128 MB RAM / 20 GB HD / 24/7/365 Tech Support Visit SoloServer, https://secure.irides.com/clientsetup.cfm. Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Request VS Application scope
Here's an interesting question: We all know that setting global variables in the request scope is faster and more thread-safe than using the Application scope, but does that remain true as we scale? Environment: 50 request variables are set in application.cfm (so they are set every time a page is called) OR 50 application variables are set one time. Scenario 1: One person hits the site. One of the following happens depending on how you've written the application: a. 50 request variables are set and five are read b. 5 application variables are read Scenario 2: 5,000 people hit the site at once (i.e. Amazon opens sale of PS2 to public). One of the following happens: a. 250,000 request variables are set and 25,000 are read b. 25,000 application variables are read with automatic read locking set to ON in the CF admin I would very much like to hear some feedback on this if anyone wants to hypothesize about the results. Bryan Love ACP [EMAIL PROTECTED] ~ Paid Sponsorship ~ Get Your Own Dedicated Win2K Server! Instant Activation for $99/month w/Free Setup from SoloServer PIII600 / 128 MB RAM / 20 GB HD / 24/7/365 Tech Support Visit SoloServer, https://secure.irides.com/clientsetup.cfm. Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
