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
th
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
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
;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
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 Applicatio
> 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 Re
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 ba
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 b
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: R
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" &
]
-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
Absolutely no problem... I do it regularly...
-Original Message-
From: Steve Vosloo [mailto:[EMAIL PROTECTED]]
Sent: 29 May 2001 08:34
To: CF-Talk
Subject: Request vs application scope
I am using the following line of code in my application.cfm
http://127.0.0.1/work/ACME/may2001/websit
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
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
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
&
> I am using the following line of code in my application.cfm
>
> http://127.0.0.1/work/ACME/may2001/website";>
>
> Then elsewhere in the site I refer all links and images to:
>
> #request.HomeDir#
>
> Is this OK to do? I'm trying to avoid using the application
> scope. Are there any known of
--
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:[E
(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
> 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
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 (
ED]]
|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]]
|&g
Isn't it a bit illogical to use request scope for storing constants if they
can be overwritten? I understand that there is no sense in doing as the variable will be destroyed no matter
what, so you have to always re-initialize it. Does that carry more or less
penalty than checking for existence o
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
.
-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
> 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 pa
> -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
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 th
> -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 upo
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
29 matches
Mail list logo
