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
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
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
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
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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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? -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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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
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 cflock scope=APPLICATION . cfif NOT IsDefined( APPLICATION.TestVar ) !--- Set up (say) 2KB of application variables --- /cfif /cflock - 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 - cfset REQUEST.(whatever) = (whatever) !--- set up the same 2KB of variables in the 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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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
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 cflock scope=APPLICATION . cfif NOT IsDefined( APPLICATION.TestVar ) !--- Set up (say) 2KB of application variables --- /cfif /cflock - 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 - cfset REQUEST.(whatever) = (whatever) . . . !--- set up the same 2KB of variables in the 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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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
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 cflock scope=APPLICATION . cfif NOT IsDefined( APPLICATION.TestVar ) !--- Set up (say) 2KB of application variables --- /cfif /cflock - 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 - cfset REQUEST.(whatever) = (whatever) .. .. .. !--- set up the same 2KB of variables in the 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 cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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
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 | | cfset request.HomeDir = http://127.0.0.1/work/ACME/may2001/website; Then elsewhere in the site I refer all links and images to: cfoutput#request.HomeDir#/cfoutput 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
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 cfif 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()? - 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 cfif 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()? - 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
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 cfif 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()? - 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? 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 cfif 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
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
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 cfapplication, 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
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 cfapplication, 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
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
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
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,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
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 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:
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 CFLOCK 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
html font size=3Here Here!!br Finally someone seems to understand/agree with my frustration on this point.br br 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.br br 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.br br I submit that the quot;right wayquot; 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.br br And I also agree with Benjamin that automatic EVERYTHING locking, implemented properly inside the Cold Fusion server, would be the true quot;right wayquot; to do it.br br At 05:47 PM 1/2/01 -0500, Benjamin S. Rogers wrote:br blockquote type=cite citegt; The reason why locking is visible to the developer is because it is muchbr gt; more efficient if the person writing the code, who knows how thebr applicationbr gt; should work, decides where to lock and more importantly what type of lockbr tobr gt; use. If the ColdFusion server had to decide whether to use a ReadOnly orbr gt; Exclusive lock, there would be enormous performance degradation.nbsp; It isbr muchbr gt; more efficient if the programmer tells the server which type of lock tobr use.br gt; It's the same thing as telling the server which scope a variable is in,br gt; instead of having the CF Server go through the variable scope hierarchy.br br This is incorrect. ColdFusion should handle all locking internally exceptbr transactional locking. I have yet to see a reason (aside from developerbr laziness) that an exclusive lock should not occur when a session variable isbr being written or a read lock should occur when a session variable is beingbr read.br br A much better analogy is that of the RDBMSs we all know and love. In thosebr environments, locking is handled by the application. If the developer needsbr to combine a series of commands into a single lock (a.k.a. a transaction),br then that option is available to the developer.br br Unlocked commands can cause dirty data at best and system instability atbr worst. I don't see why this would be the default behavior of ColdFusion asbr opposed to locking all commands except where the developer chooses tobr override this to ensure transactional integrity.br br I've argued this point before, both on this list and elsewhere. I maintainbr that the issues with lt;CFLOCKgt; are the result of asking a single threadedbr application server to behave as a multithreaded application server. Ratherbr than rewrite the portions of the ColdFusion server that did not behavebr properly in a multithreaded environment, they have shuffled off thisbr responsibility to ColdFusion developers.br br Benjamin S. Rogersbr Web Developer, c4.netbr voice: (508) 240-0051br fax: (508) 240-0057br br br ~~ 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 CFLOCK 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