[thelist] CF Session Variables
Raymond Camden
jedimaster at macromedia.com
Tue Oct 2 16:14:52 CDT 2001
> I don't know the answer to the first question, but maybe I
> can shed some light on the second.
>
> My understanding is that the name attributes provides a
> unique identifier to the lock. When you lock with a name, it
> will be single threaded with all other locks with the same
> name on a server wide scale. This way, you are not locking
> the entire session scope on the server like you would if you
> just said scope="session"
However, this is only an issue for EXCLUSIVE locks, not read locks.
> If you lock the scope "session", then all locks of scope
> "session" within the application will have to wait for you to
> close the lock before they can continue. But, if you use a
See above. This statement is incorrect for read locks.
> specific name, then only those locks with the same name as
> the lock in question have to wait. This is much more
> flexible than locking an entire scope.
Perhaps, but it is also much more dangerous. If you are not doing your
named locks perfectly, then you will have a possibility of corruption.
Consider this. Imagine you have a large Application structure. This
structure has 2 keys:
Application.MyStuff
Application.YourStuff
Both of these keys are large structs in themselves. Let's say you want
to work on Application.MyStuff. You think, "Hmm, whenever I work in the
area, I'll use the name, 'MyStuff'. So, you do stuff like this:
<CFLOCK NAME="MyStuff" TYPE="Exclusive" TIMEOUT=3>
<CFSET Application.MyStuff.Foo = "Goo">
</CFLOCK>
You get the idea.
The problem with this, however, is that it doesn't safely handle the
fact that, yes, your updating a _portion_ of Application, but you _are_
still working with Application.
We had a big discussion about this, and the _only_ safe way to use NAMEd
locks and shared access vars is with locks in trees. I.e.:
<CFLOCK NAME="ApplicationName" ...>
<CFLOCK NAME="MyStuff">
...
</CFLOCK>
</CFLOCK>
This also increases the chances you will screw up.
In almost every case I'd recommend using SCOPE locks. The only time I
use NAME locks is when I'm working with file based tags, Verity, etc.
> Also, we discovered a while back that you should not do a
> cflocation within a cflock as it does not always release the lock.
This should not be an issue. I talked to one of our engineers about
this, and he said that we should be safely handling cases like this.
However, let me say I'm only 99.9% sure of this.
=======================================================================
Raymond Camden, Principal Spectra Compliance Engineer for Macromedia
Email : jedimaster at macromedia.com
Yahoo IM : morpheus
"My ally is the Force, and a powerful ally it is." - Yoda
More information about the thelist
mailing list