Re: request vs application scope

[Sean A Corfield]

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

[Jim Davis]

 -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

request vs application scope

[Mauricio Giraldo]

(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

request vs application scope

[Mauricio Giraldo]

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

RE: request vs application scope

[Mike Brunt]

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

[Mauricio Giraldo]

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

[Jim Davis]

 -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

[Mauricio Giraldo]

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

request vs application scope

[Mauricio Giraldo]

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

Request vs application scope

[Steve Vosloo]

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

[Daniel Lancelot]

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

[Steve Vosloo]

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

[Daniel Lancelot]

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

[Steve Vosloo]

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

[Dave Watts]

 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

[alistair . davidson]

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

[Daniel Lancelot]

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

[Dave Watts]

 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

[alistair . davidson]

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

[Patricia Lee]

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

[stas]

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

[Steve Bernard]

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

[Jones, Matt]

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

[Dave Watts]

 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

Request vs. Application scope

[Jason Lotz]

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: Request vs. Application scope

[Todd Ashworth]

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

[Jason Lotz]

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

[Bryan Love]

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: Automatic locking (was: Request VS Application scope)

[Peter Theobald]

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=15803rid=972879910type=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)

[Dave Watts]

 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

Request VS Application scope

[Bryan Love]

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

[Greg Wolfinger]

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

[Peter Theobald]

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

[Greg Wolfinger]

 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

[Jeremy Allen]

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

[Greg Wolfinger]

 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

[Benjamin S. Rogers]

 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

[Peter Theobald]

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

[Peter Theobald]

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