esday, September 24, 2002 9:40 AM
To: CF-Talk
Subject: RE: WHY!!
> > What I do know is that if you don't lock memory
> > variables in CF 5 or earlier, your server will
> > typically crash under load, and if you consistently
> > lock memory variables with th
> > What I do know is that if you don't lock memory
> > variables in CF 5 or earlier, your server will
> > typically crash under load, and if you consistently
> > lock memory variables with the SCOPE attribute, your
> > server won't crash under load.
>
> I agree that empirical testing is the wa
p; CEO
Montara Software, Inc.
http://www.montarasoftware.com/
888-408-0900 x901
> -Original Message-
> From: Dave Watts [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 23, 2002 4:28 PM
> To: CF-Talk
> Subject: RE: WHY!!
>
> > > Just curious, do pre-MX
> yeah, I get that, but I guess what im looking for is
> something like...
>
> 1 cfset = wait for processing 1 sec.
> 1 cfset + 1 whatever = wait for proc. 2.5 secs.
>
> are there any metrics or best practices for this?
No, I'm not aware of any. The thing is, you're not concerned with how long
> > Just curious, do pre-MX versions of CF require
> > scope-level locking (as opposed to named locks)
> > for safe access to session variables?
>
> No they don't require it. In fact scope locking only
> came in as a cool new feature with CF4.5 . Logically
> both will do the job, although as J
> Just curious, do pre-MX versions of CF require scope-level
> locking (as
> opposed to named locks) for safe access to session variables?
No they don't require it. In fact scope locking only came in as a cool
new feature with CF4.5 . Logically both will do the job, although as
Jason pointed ou
nal Message-
> From: Smith, Matthew P -CONT(DYN)
> [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 23, 2002 1:07 PM
> To: CF-Talk
> Subject: RE: cflocking de-mystified (was RE: WHY!!)
>
>
>
> But if you access two variables in the same scope(ie session)
On Sunday, September 22, 2002, at 10:51 , Dave Watts wrote:
> 2. If you're using any version of CF which supports the SCOPE attribute
> (4.5+, I think), use that with your CFLOCK tags around memory variables.
Just curious, do pre-MX versions of CF require scope-level locking (as
opposed to named
I would add - do a copy (as in
If you just re-reference it to another scope (as in ), you have not solved your problem
-mk
-Original Message-
From: Sharon DiOrio [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 23, 2002 2:29 PM
To: CF-Talk
Subject: Re: WHY!!
> 1, is it
> 1, is it in fact necessary in MX and
It's pretty much necessary regardless of MX.
> 2, Is an Application.array the best place to store this kind of thing?
That depends. Is the information something that is shared across the
application and not something that changes frequently? If so, absol
PM
>>To: CF-Talk
>>Subject: RE: cflocking de-mystified (was RE: WHY!!)
>>
>>Right - I use the name attribute for cflock rather than scope
>>(occasionally) because my understanding is that when you lock on the
>>scope you Lock the entire scope down for tha
> The array is being written to and read from at least a dozen times a
minute
> But then I keep getting the same symptom - MX freezes up at 100% CPU
> every four or five hours. Plenty of memory and storage.
Entirely asside from MX and whether or not locking is necessary, if you have
2 pages w
--
From: Blum, Jason (SAA) [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 23, 2002 12:07 PM
To: CF-Talk
Subject: RE: WHY!!
Maybe I can jump in on this thread with a related question - Dave and
others keep emphasizing that it isn't necessary to lock in MX.
I am using a large Appli
You're probably having a race condition occurring. Those still required locks.
- Original Message -
From: "Blum, Jason (SAA)" <[EMAIL PROTECTED]>
Date: Monday, September 23, 2002 11:06 am
Subject: RE: WHY!!
> Maybe I can jump in on this thread with a rel
ocess waiting on a slow process - essentially denying
client access because of scope locking...
Jason
CFDynamics.com
> -Original Message-
> From: Tony Weeg [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 23, 2002 7:53 AM
> To: CF-Talk
> Subject: cflocking de-mystif
o: CF-Talk
Subject: RE: WHY!!
> i havent used locks on session vars, havent
> needed to, and having never formally learned
> cf, not really 100% down with the thought
> process behind locking session var setting...
The thought process is very simple. If you're running CF 5
www.navtrak.net
TW> 410.548.2337
TW> -Original Message-
TW> From: Dave Watts [mailto:[EMAIL PROTECTED]]
TW> Sent: Monday, September 23, 2002 10:35 AM
TW> To: CF-Talk
TW> Subject: RE: cflocking de-mystified (was RE: WHY!!)
>> now, I guess my next question would
Management Solutions
www.navtrak.net
410.548.2337
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 23, 2002 10:35 AM
To: CF-Talk
Subject: RE: cflocking de-mystified (was RE: WHY!!)
> now, I guess my next question would be, is the cfl
> now, I guess my next question would be, is the cflock
> timeout sort of an arbitrary guess as to what would be
> a good amount of time? I mean, how long are the lock
> timeouts on the heaviest hit cf pages set for? whats
> a good number?
42.
Seriously, the number will depend on what you're
02 1:52 AM
To: CF-Talk
Subject: RE: WHY!!
> i havent used locks on session vars, havent
> needed to, and having never formally learned
> cf, not really 100% down with the thought
> process behind locking session var setting...
The thought process is very simple. If you'
> no, but ill try that.
> +++ im trying now. ++
> not lookin good...its a shared server
> environment, experthost.com. can they block
> locking capabilities?
No, they can't disable the tag...
> i havent used locks on session vars, havent
> needed to, and having never formally lear
Tony,
You may find the following link useful:
ColdFusion Server (Versions 5 and Prior): ColdFusion Locking Best Practices
TechNote 20370
http://www.macromedia.com/v1/handlers/index.cfm?ID=20370&Method=Full
cheers
David
__
T
> i havent used locks on session vars, havent
> needed to, and having never formally learned
> cf, not really 100% down with the thought
> process behind locking session var setting...
The thought process is very simple. If you're running CF 5 or earlier, and
you're using session variables, and y
lto:[EMAIL PROTECTED]]
Sent: Monday, September 23, 2002 12:41 AM
To: CF-Talk
Subject: Re: WHY!!
Tried a session lock around your session vars?
> for the love of jehovah could
> someone please tell me why in the heck
> these two lines are making a page stall
> to the point of
Tony,
>
>
What happens if you try each line individually - this would tell you if it
is stalling on the cookie or the set.
Cheers
David
-Original Message-
From: Tony Weeg [mailto:[EMAIL PROTECTED]]
Sent: Monday, 23 September 2002 1:59 PM
To: CF-Talk
Subject: WHY!!
f
Tried a session lock around your session vars?
> for the love of jehovah could
> someone please tell me why in the heck
> these two lines are making a page stall
> to the point of never coming back when loading?
> when i comment them, the page shows the rest
> of the page fine, however when not
Are you locking the CFSET? Session vars can hang the server if it's under
stress and the statement isn't locked...
-Original Message-
From: Tony Weeg [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 22, 2002 9:29 PM
To: CF-Talk
Subject: WHY!!
for the love of jeh
for the love of jehovah could
someone please tell me why in the heck
these two lines are making a page stall
to the point of never coming back when loading?
when i comment them, the page shows the rest
of the page fine, however when not commented
out, they make the page just sit in limbo?
cf5 i
28 matches
Mail list logo
