-- Original Message --
from: Shawn Grover <[EMAIL PROTECTED]>
>For those of you adverse to locking, why not simply set the server to lock
>all reads?
The Auto-read locking has some major problems with locking ALL reads. Things like
StructFind and IsDefin
-- Original Message --
from: "Keith Meade" <[EMAIL PROTECTED]>
>BTW, a corollary of this is that, if your site does not use frames, ***you
>don't have to worry about locking session variables ever***. Regardless of
>the setting of "Single Threaded Sessions"
Doesn't single-threading work only on the session? This is, single-threading the
SESSION, not the entire CFserver?
The text from the CFadmin single-thread setting on our CF4.5.1 is:
"
Single Threaded Sessions
When checked, all requests are single threaded by session ID. This guarantees that an
> Am I missing a performance issue on this? Is there some
> reason why this
> option wouldn't be reasonable?
>
> Shawn Grover
>
> -Original Message-
> From: Keith Meade [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 22, 2001 1:01 PM
> To: CF-Talk
&
cause of this error but it certainly puts the odds up
more!!
-Original Message-
From: Kinley Pon [mailto:[EMAIL PROTECTED]]
Sent: Monday, 26 November 2001 3:32 AM
To: CF-Talk
Subject: Re: Complete lack of locking...
Just to agree that "It is true that as long as there is no u
> Just to agree that "It is true that as long as there is no
> use of FRAMES, there is no need of locking session variables.
> When using frames, the entire page is rendered at one time
> which may cause a deadlock if the same session variable is
> being reference.
Unfortunately, again, that
Suh" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: CF-Talk <[EMAIL PROTECTED]>
>Subject: Re: Complete lack of locking...
>Date: Thu, 22 Nov 2001 13:23:43 -0700
>
>Let me add as well that, yeah, the single threaded session thing shouldn't
>be such a performa
ttp://www.c4.net/
v.508.240.0051
f.508.240.0057
- Original Message -
From: "Shawn Grover" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 2:07 PM
Subject: RE: Complete lack of locking...
> For those of you adverse to l
> I guess I'm hoping that future versions of CF will require *less* locking.
> The whole locking thing is silliness that should be handled automatically
> within CF.
>
> But the important point is that the "Single Threaded Sessions"
> option makes session variable locking unnecessary. And I'll be
t;
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 3:07 PM
Subject: Re: Complete lack of locking...
> I have never seen this stated before - can you explain further please?
> I've just assumed that all session variables must be locked.
>
> Ta
>
I have seen first hand some "nasty" side effects of not locking. (like
spontaneous re-boots and sessions getting "mixed"). Code as you please. It
is your server :-)
> I have never seen this stated before - can you explain further please?
> I've just assumed that all session variables must be
I have never seen this stated before - can you explain further please?
I've just assumed that all session variables must be locked.
Ta
Seamus
>BTW, a corollary of this is that, if your site does not use frames, ***you
>don't have to worry about locking session variables ever***. Regardless of
ROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 1:20 PM
Subject: Re: Complete lack of locking...
> Sorry. My experience is otherwise. Not that I've done a major amount of
> testing. Maybe I should do more. I'm generally happy
F-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 2:07 PM
Subject: RE: Complete lack of locking...
> For those of you adverse to locking, why not simply set the server to lock
> all reads?
> Doing so means you can refer to you session variables (and others that
&g
>
> - Original Message -
> From: "Kwang Suh" <[EMAIL PROTECTED]>
> To: "CF-Talk" <[EMAIL PROTECTED]>
> Sent: Thursday, November 22, 2001 1:50 PM
> Subject: Re: Complete lack of locking...
>
>
> > Not urban legend.
> >
> > We
he tags.
- Original Message -
From: "Kwang Suh" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 1:50 PM
Subject: Re: Complete lack of locking...
> Not urban legend.
>
> We had the dev server here on &quo
al Message-
From: Keith Meade [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 22, 2001 1:01 PM
To: CF-Talk
Subject: Re: Complete lack of locking...
I guess I'm hoping that future versions of CF will require *less* locking.
The whole locking thing is silliness that should be handle
#x27;ll bet a dollar that it doesn't
have a discernable affect on real-world performance. Plus you get cleaner
code.
- Original Message -
From: "Philip Arnold - ASP" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, Novembe
AIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 10:10 AM
Subject: Re: Complete lack of locking...
> No offense, but it sounds like urban legend to me. Assuming it's properly
> implemented, the "Single Threaded Sessions&quo
> No offense, but it sounds like urban legend to me. Assuming it's properly
> implemented, the "Single Threaded Sessions" option should only have a
> significant effect in situations where two ColdFusion requests
> are being made at the same time within the same session, i.e. when two
> browser f
ssage -
From: "Philip Arnold - ASP" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Thursday, November 22, 2001 4:40 AM
Subject: RE: Complete lack of locking...
> > Why not just enable the "Single Threaded Sessions" option? D
> AFAIK, the single threaded locking session does not mean or action this ;
>
> "That'd mean that only one person who access the site at a time - severely
> limiting the access to the site"
Sorry, true - this only effects the Sessions, not Server or Client scope
I was thinking it effected everyt
AFAIK, the single threaded locking session does not mean or action this ;
"That'd mean that only one person who access the site at a time - severely
limiting the access to the site"
Neil
Team Macromedia
~~
Get the mailserver that powers this list
> Why not just enable the "Single Threaded Sessions" option? Doesn't that
> eliminate the need to lock session-scoped variable access?
DRASTIC!
That'd mean that only one person who access the site at a time - severely
limiting the access to the site
It'd be a LOT safer to re-write the applicati
Why not just enable the "Single Threaded Sessions" option? Doesn't that
eliminate the need to lock session-scoped variable access?
~~
Your ad could be here. Monies from ads go to support these lists and provide more
resources for the community. ht
For now go into CF ADMIN
and set
Single Threaded Sessions
When checked, all requests are single threaded by session ID. This
guarantees that any potential variable contention caused by simultaneous
requests in the same session will not occur. Also, when checked, CFLOCK is
no longer needed to lo
> I inherited an application that uses session variables and
> has no CFLOCK tags in it at all! All session variables have
> a CFPARAM in the Application.cfm, but even there it isn't
> inside a cflock. I was reading the docs and even if I set
> the locking to "Automatic Read Locking", I don't
Steven, I would take a look at using the Request scope where you can
although that is a bit of a rub. Because I think you can only determine
where to do this by knowing exactly what the application does and how it
does it. Another approach (although I am sure this will be frowned on by
some) is
yup
- Original Message -
From: "Steven Monaghan" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Wednesday, November 21, 2001 1:39 PM
Subject: Complete lack of locking...
> I inherited an application that uses session variables and has no CFLOCK
> tags in it at all! All sessi
Yup. Have fun.
- Original Message -
From: "Steven Monaghan" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Wednesday, November 21, 2001 1:39 PM
Subject: Complete lack of locking...
> I inherited an application that uses session variables and has no CFLOCK
> tags in it at a
30 matches
Mail list logo