I guess this would be the answer I was looking for?
From: Barney Boisvert
Subject: RE: [CFCDev] CFCs in memory
Date: Mon, 28 Jul 2003 18:36:40 -0700
----------------------------------------------------------------------------
----
My understanding is that the read lock is unneeded in CFMX. You only need
CFLOCK for preventing race conditions in CFMX, not for syncronizing memory
access, because the underlying java runtime takes care of that for you. You
obviously still have to lock the initialization, because that's preventing a
race condition, not just protecting memory.
My preference is something like this:
------------------------------------------------------------------------
<cfset reloadAppVars = structKeyExists(application, "app_vars_loaded")/>
<cfif reloadAppVars>
<cflock scope="application" type="exclusive">
<cfif structKeyExists(application, "app_vars_loaded")>
.. do whatever ..
<cfset application.app_vars_loaded = true />
</cfif>
</cflock>
</cfif>
------------------------------------------------------------------------
CF will ensure that my structKeyExist() doesn't screw up memory, and then
the CFLOCK will ensure that I never initialize anything twice. You
_definitely_ need the second check as to whether or not to proceed with the
initialization inside the CFLOCK tag, or you might initialize twice. The
first check is just to alleviate the overhead of processing the CFLOCK tag
when it's unneeded, which will be any request that arrives after the first
request finishes loading the variables. It's those non-initial requests
that arrive before the first request finishes loading the variables that all
the locking is there to deal with.
barneyb
---
Barney Boisvert, Senior Development Engineer
AudienceCentral
-----Original Message-----
From: Sparrow-Hood, Walter
To: [EMAIL PROTECTED]
Sent: 9/18/03 2:32 PM
Subject: RE: [CFCDev] OT: Locking
In MX you only have to lock to prevent race conditions. Check the
archive
for more info.
-----Original Message-----
From: Cohen, Michael [SMTP:[EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 2:18 PM
To: '[EMAIL PROTECTED] '
Subject: [CFCDev] OT: Locking
This may sound stupid but did I read somewhere that it *really* wasn't
necessary to lock writes to shared scope variables in MX? That seems
impossible to me but...
Also, assuming you do have to lock writes, is it preferable to use the
name
attribute rather than scope? And if so, what is the behavior? Is it that
the
lock only affects other locks with the identical name? And that you
should
use different lock names if you are writing to different variables? For
instance,
<!---lock one session variable---->
<cflock name="session.UserID" type="exclusive" timeout="10">
<cfset session.UserID = someValue />
</cflock>
<!---on another page---->
<cflock name="session.Cart" type="exclusive" timeout"10">
<cfset session.Cart = aStructure />
</cflock>
Would these locks have no bearing on each other? i.e. two threads could
hit
each piece of code at exactly the same time and both would execute
immediately? And is this best practice, that you use different lock
names if
you're writing to different variables? And this is more efficient than
using
the scope attribute because something like scope="session" would
needlessly
lock everything in the session scope?
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[EMAIL PROTECTED]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the word 'unsubscribe cfcdev'
in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
