> From what I've read so far, the standard lock name relates
> to the scope being accessed. For example, accesses to the
> application scope use a lock name of #Application.ApplicationName#
> and accesses to the session scope use a lock name that is unique
> to that user session, such as the concatenation of the CFID
> and CFTOKEN.
>
> If I have two different structures stored in the application
> scope, could I use separate names when accessing each structure,
> thereby increasing performance because users reading one struct
> aren't affected by users accessing the other?
>
> I store a great deal of information in the shared scopes. As a
> result, almost every page in my application reads *something* from
> the shared scope. If I use the application name as the lock name
> then two simultaneous users doing totally different tasks could
> be affected by the other user's lock. If I use names that relate
> to the task or data being read then it seems to me that this
> wouldn't happen.
>
> The only thing I can think of that would make this a bad idea
> is if the entire scope needs to be locked, not just parts of it.
> Any ideas?
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. Not knowing the internals of the CF
server, I can only guess why that might be. Perhaps the list of variable
names itself, being stored in the scope, shouldn't be read concurrently by
multiple requests, and thus the scope itself should be locked.
Your safest bet is to lock the entire scope.
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. If you had a block of code which changed lots of memory variables in
the midst of doing other stuff, you might want to put the changes into local
variables temporarily, then copy the contents of the local variables back to
the Session scope all at once. It certainly gives you something to think
about. I'm not sure exactly what the right answer is, and there may in fact
be no single correct approach - it may vary depending on the situation.
The one thing you don't want to do is confuse the picture you see of how
memory variables work with the underlying reality of how they actually do
work. We generally do this all the time; we build functional models which
describe how something works, and as long as that functional model explains
the behavior of the real thing, it's good enough for us. In our functional
model, we have these three memory scopes, and each one of them is a
container that we don't really have to think about - we just put things into
each, and retrieve those things when we want them. That's a useful
functional model, but it doesn't describe what's going on at a lower level.
It ignores threads, mutexes, and all the other stuff that's going on. Given
that functional model, your questions about locking make sense. Why can't we
just lock the single thing that we're using? 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.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
------------------------------------------------------------------------------
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.
