Dave,
Thank you for your comments to both of my threads.
>Given that Allaire recommends the use of the SCOPE attribute to lock memory
>variables instead of the NAME attribute, there is probably some reason
you'd
>want to lock access to the entire scope.
I didn't consider that point. I use CF 4.01, so I don't use the SCOPE
attribute, but it is definitely something worth considering.
>Now, following this logic, there are a lot of things to consider when we
use
>memory variables that most of us probably haven't thought too much about.
>For example, when I started using Session variables in CF 3.x, I might
>sprinkle them liberally throughout a page. If I continued to do that, I'd
>either have to use CFLOCK around most of the page, or have lots of CFLOCKs
>in the page around each read of a Session variable. The first approach
would
>certainly be simpler, but then pages would more likely run into concurrency
>issues.
>
>The approach that seems the sanest, in this situation, is to copy the stuff
>you need from the memory scope into local variables in one fell CFLOCKed
>swoop.
This is what I do. Since most of my cached data is either strings or
structures I use one of two methods to create "local" copies.
1) If the cached data is a string, I create a local copy by using (in a
CFLOCK of course):
<CFSET strLocal = Application.strCached & "">
Since CF passes by reference if you leave out the concatenation with the
blank string then strLocal is simply a reference to the data in the shared
scope. It is my understanding that referring to this variable outside a
CFLOCK would, in effect, be an unlocked read of the shared scope, and thus
subject to corruption. (Note: this was pointed out to me on the Allaire
forums by one of the CF "gurus" such as Hal Helms, Ben Forta, or Nate Weiss)
By assigning the local variable the value of an operation (such as the
concatenation) CF creates a new variable, rather than creating a reference
to the data in the shared scope.
2) If the cached data is a structure, then I use StructCopy() inside a
CFLOCK to create a local copy of the structure. Again, since CF passes by
reference simply assigning a local variable to the structure in the shared
scope (<CFSET stcLocal = Application.stcCached>) only creates a reference to
the data in the shared scope.
3) NOTE: I do NOT know of any way to create a local copy of a query saved in
a shared scope. If I have a query in Application.qryCached, creating a
"local" copy seems to be a moot point.
Example:
<CFSET qryLocal = Application.qryCached>
only creates qryLocal as a reference to the shared data. Any writes to that
query (QuerySetCell, QueryAddRow, etc) *will* affect the data in the shared
scope. This indicates to me that in order to truly protect accesses to the
shared scopes, CFLOCK must be used around every single access to any query
stored in those scopes, and that trying to create a "local" copy of said
queries is a pointless venture.
>Unfortunately for us, we need
>to know things that the functional model just doesn't tell us. In the
>absence of that knowledge, your best bet is to write your code
>conservatively; prepare for the worst.
I guess that's the road I will take. Again, thank your for your comments.
Regards,
Seth Petry-Johnson
Argo Enterprise and Associates
------------------------------------------------------------------------------
Archives: http://www.eGroups.com/list/cf-talk
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
