On Monday, Jan 13, 2003, at 22:27 US/Pacific, Matt Robertson wrote:
Client vars are, for my money, the Holy Grail with respect to
completely
replacing session vars. Scaleable to clusters, zero locking issues,
maintain state, and expiration can be controlled precisely like session
vars with
Yes. Yes.
-- Original Message --
From: Webmaster [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
date: Sun, 12 Jan 2003 15:23:55 -0500
Hi,
If I reference an APPLICATION var using isDefined, do I have to read lock
it. Is the var really being read?
No, it isn't, because I presume you'll have an EXCLUSIVE lock in the include
file, putting an EXCLUSIVE lock inside a READONLY lock. Bad, bad, bad.
We've found using Application variables generally isn't necessary. We
include a file in Application.cfm that sets all the global variables we need
in
If you are going to put initialization code like this in your
Application.cfm file, just be sure that you do not use any code that
can generate another HTTP request for another CFM file (such as a
cfhttp tag) as you may either create an infinite loop (with a readonly
lock) or a deadlock
I got a tip previously on cf-talk that advised me to do
this in my application.cfm:
!--- Page By Page Session Variables ---
CFIF IsDefined(Session.Collections)
cflock scope=session type=readonly timeout=20
cfset request.session = duplicate(session)
/cflock
Dave Watts wrote
In general, I'm not a big fan of this approach,
Me neither, especially since not locking the session var in the
isdefined() as was shown in the original post is improper. You would
have to lock the whole thing, cfif isdefined and all.
Client vars are, for my money, the Holy
On Sunday, Jan 12, 2003, at 12:23 US/Pacific, Webmaster wrote:
If I reference an APPLICATION var using isDefined, do I have to read
lock
it. Is the var really being read?
No, but...
If you are trying to avoid a race condition, you may need to lock. See
my blog entry:
- Original Message -
From: Webmaster [EMAIL PROTECTED]
If I reference an APPLICATION var using isDefined, do I have to read
lock
it. Is the var really being read?
---
Yep - if you're not on CFMX, even IsDefined(sharedScope.varName) needs a
lock around it. If
While there arguably are circumstances where you don't need to lock, if
you just do it always, everywhere (subject to the smart use of temp vars
as was pointed out already), your code will work properly. I have yet
to see any instance where locking instituted any noticeable performance
penalty at
On Sunday, Jan 12, 2003, at 13:23 US/Pacific, Matt Robertson wrote:
I have yet
to see any instance where locking instituted any noticeable performance
penalty at any level.
If you lock within Application.cfm, you will single-thread your
application and it will not scale. For low-traffic
Sean A Corfield wrote:
On Sunday, Jan 12, 2003, at 13:23 US/Pacific, Matt Robertson wrote:
I have yet
to see any instance where locking instituted any noticeable performance
penalty at any level.
If you lock within Application.cfm, you will single-thread your
application and it will not
I got a tip previously on cf-talk that advised me to do this in my
application.cfm:
!--- Page By Page Session Variables ---
CFIF IsDefined(Session.Collections)
cflock scope=session type=readonly timeout=20
cfset request.session = duplicate(session)
/cflock
/CFIF
On Sunday, Jan 12, 2003, at 14:20 US/Pacific, Jochem van Dieten wrote:
Sean A Corfield wrote:
If you lock within Application.cfm, you will single-thread your
application and it will not scale. For low-traffic applications, that
may be fine.
I think that is a bit of an oversimplification.
.
Matt Robertson [EMAIL PROTECTED]
MSB Designs, Inc. http://mysecretbase.com
-Original Message-
From: Sean A Corfield [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 12, 2003 2:00 PM
To: CF-Talk
Subject: Re: Another
14 matches
Mail list logo
