ColdFusion 5 automatic scope locking question

[anclarke]

Hi. I have a client with an old application hosted on ColdFusion 5.x. The
application developer didn't use cflock for most of the session scope variable
accesses, and this seems to be causing ColdFusion lockups.

Rather than go through all the code and put the locks in, I first recalled
that in CF5 there was a way of setting up automatic read locks for the session
scope. Check out
[url]http://livedocs.adobe.com/coldfusion/5.0/Developing_ColdFusion_Applications/appF[/url]
ramework10.htm for what I'm talking about.

I told the client to set up "automatic read locking", which they say they did,
and now they're getting errors like this across the site:

session.someVar = someOtherVar
Error near line 129, column 8.
Symbol session.someVar is in a scope that contains data shared across threads
and cannot be accessed without an active lock.

I'd have expected this error if the client had set up Full Checking, not
Automatic Read Locking. I don't think these errors were happening before they
made the change to the ColdFusion Administrator.

Did I misunderstand what that setting was for, or did my client just check the
"Full Checking" box and tell me they checked "Automatic Read Locking"?

Thanks a lot,
- Andrew Clarke.

[Adam Cameron]

I think this sentence, from the docs you mention, probably explains it:

"If your application writes to any variable in the scope without protecting
it with a lock, ColdFusion generates an exception error."

Which is what is happening. You're trying to write to session.someVar
without locking it.

You need to either:
1) modify the code to lock it properly;
2) upgrade to CFMX.

You should be able to bill your client for either of these. It sucks a bit
for them as they were dropped in the sh*t by the previous developer, but
sh*t happens, and now they have little choice.

To be honest, I'd suggest upgrading. CF5 is dead technology.

--
Adam

[anclarke]

Good point on the write issue. I didn't notice that in the documentation, and
for some reason I guess I just presumed that the previous developer had at
least written locks around variable WRITES.

I'll mention again that upgrading to MX would alleviate their problems.

Thanks for pointing out (what should have been) the obvious,
- Andrew.