[thelist] cflock reads?

[rudy]

> You need to lock the read in case of another page updating it,
> particularly in the case of frames.  You are correct, logically it
> should never happen, but a "better safe than sorry" approach
> in CF code design.

thanks chris, but again, i have a hard time understanding this when we're
talking about *session* variables -- application variables maybe

i can understand almost-simultaneous session hits from a double click, but
not where frames are concerned (but let's snot go there, because i will
never code a framed site)

and shouldn't the collision be controlled by an exclusive lock on the
update?  so that if a simultaneous update *does* try to take place, it has
to *wait* until the read is finished?

i'm afraid i still don't understand why the session *read* has to be locked


oh, and another thing --

if the session value actually changes between the time the read is
initiated and the read is completed (which i still cannot understand how
this would happend *for the same user*), my question is SO WHAT?

i mean, what difference does it make?  ***it's the SAME user***

boy, am i thick-headed today


rudy