[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