hence the 'usually'. ;)
Also, it's worth mentioning that locking needn't be performed with the
CFLOCK tag, although that's usually the most convinient. And you don't have
to lock by scope, you can lock by name.
For read-only variables in particular, you can perform locking without
actually using CFLOCK for read access. Simply ensure that no request ever
gets to the processing part without having the full set of variable set, and
you needn't lock any access, asuming ALL access is read only.
For example:
<cflock scope="application" type="Readonly">
<cfset needAppVarLoad = NOT structKeyExists(application,
"app_vars_loaded") />
</cflock>
<cfif needAppVarLoad>
<cflock scope="application" type="exclusive">
<cfif NOT structKeyExists(application, "app_vars_loaded")>
<cfset application.whatever = something />
...
<cfset application.app_vars_loaded = true />
</cfif>
</cflock>
</cfif>
If that's in your Application.cfm file and all variables are read-only, you
can safely access them without a CFLOCK tag, because no request will ever
get past the second CFLOCK tag unless there is a completely generated set of
application variables that won't ever change.
barneyb
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
[EMAIL PROTECTED]
voice : 360.756.8080 x12
fax : 360.647.5351
www.audiencecentral.com
> -----Original Message-----
> From: Dave Carabetta [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 07, 2003 10:52 PM
> To: CF-Talk
> Subject: Re: session/client variables 101
>
>
> > CFLOCK is no longer necessary to prevent memory corruption, but it is
> still
> > necessary to prevent race conditions in your code. In other
> words, if you
> > need to ensure that only a single request at a time can access
> a resource
> > (whether a variable in a shared scope, a file on the filesystem, or
> > something else) you still need CFLOCK. You can usually get away without
> > locking session access, as long as your site doesn't use frames, but you
> > should still put it in there where appropriate.
> >
>
> I don't entirely agree here, and I say this out of experience. You don't
> need to lock when you're *initially* writing to the shared-scope
> variable in
> question. However, you do need to lock in all other cases, and
> frames aren't
> the only instance.
>
> If I open a browser and then Ctrl+N to open a new browser, that's still
> technically a part of the same session, regardless of whether or not I'm
> using frames. I would still want to lock to prevent a single user from use
> simultaneously writing a variable value at the same time.
>
> I think sometimes "race conditions" get exemplified as <cfset
> session.foo =
> session.foo + 1>. But I think those situations are actually more rare than
> multiple browser instances. In my personal opinion, always lock
> -- it's just
> safer that way.
>
> Regards,
> Dave.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Get the mailserver that powers this list at
http://www.coolfusion.com
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
