[thelist] cflock reads?

Pete Freitag pf at cfdev.com
Mon Jan 21 16:23:00 CST 2002


Chris,

	I believe their motivation for not handling locking internally was for
performance.  When you leave it up to the programmer's code to determine
when to do locking, that's one less conditional in the server code.  Whether
that is a really good reason or not is very debatable.

_____________________________________________
Pete Freitag (pfreitag at cfdev.com)
CFDEV.COM
Web Developer Resources
http://www.cfdev.com/


-----Original Message-----
From: thelist-admin at lists.evolt.org
[mailto:thelist-admin at lists.evolt.org]On Behalf Of Chris Evans
Sent: Monday, January 21, 2002 4:49 PM
To: thelist at lists.evolt.org
Subject: RE: [thelist] cflock reads?


I think you are missing a couple of aspects of the way CF handles locks:

1) Because shared variables are stored in memory, simultaneous reads and
writes will cause memory errors that crash the server.  I've never heard a
really good reason why CF doesn't lock these internally, transparent to the
programmer, but that's the way it goes.

2) A READ lock only prevents an exclusive lock from taking place.  Exclusive
locks prevent READ and EXCLUSIVE locks.  So you can have a bunch of
simultaneous reads going on, but if you want to update that variables, you
have to wait until all READ locks are complete, then your EXCLUSIVE lock
kicks in, preventing anybody else form reading or writing until the update
is complete.

3) You lock session variables the same way you handle other shared variables
because CF treats them internally the same way.  Cases are rare that you
would get contention, but better safe than sorry.

Hope that helps,

Chris Evans
chris at fuseware.com
http://www.fuseware.com



-----Original Message-----
From: thelist-admin at lists.evolt.org
[mailto:thelist-admin at lists.evolt.org]On Behalf Of rudy
Sent: Monday, January 21, 2002 4:29 PM
To: thelist at lists.evolt.org
Subject: Re: [thelist] cflock reads?


> 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


--
For unsubscribe and other options, including
the Tip Harvester and archive of TheList go to:
http://lists.evolt.org Workers of the Web, evolt !



--
For unsubscribe and other options, including
the Tip Harvester and archive of TheList go to:
http://lists.evolt.org Workers of the Web, evolt !





More information about the thelist mailing list