Alan, this is a source of frequent confusion. First let's restate that in
both CFMX and BlueDragon, because they're built atop Java and synchronize
variable accesses internally, the issue of locking is only really relevant
any more with respect to "race conditions", or attempts to update a given
variable in one thread and read or update it at the same time in another.
Even so, and especially prior to CFMX and BlueDragon, it's important to
understand what locks do and don't do. There's a lot of misunderstanding out
there.
I'd assert that your first guess is the most accurate. The bottom line is
that all a CFLOCK does is simply declare that a given block of code should
be protected in such a way that if other threads other threads should be
kept from running ("synchronized") if:
1) they're executing the same template in which the lock occurs, or
2) they're executing code that uses a CFLOCK that respects the running
template's lock
Most folks don't have trouble getting number 1, above, talking about other
threads running the program in question.
Perhaps less obvious is when we're talking about number 2, other templates
using locks that respect the given lock. As you assert, something doing an
exclusive lock will prevent execution of other threads also doing either
exclusive or readonly locks against the same scope (assuming a SCOPEd cflock
is being used).
But the real source of confusion is that a CFLOCK will NOT--WILL
NOT--prevent execution of threads that are doing no locks at all. If a
template uses no locking and updates a thread, it's basically a rogue that
eliminates the value of all the other locking you've done.
This is why (prior to MX and BlueDragon) it didn't matter if you were really
careful locking all your code. All it took was for one other template that
didn't do locking to access the same variable scope, and bang, you had the
chance for corruption.
Yes, CFMX and BlueDragon reduce the need for worry about it (you only need
to do locks to prevent race conditions, as discussed at
http://www.macromedia.com/support/coldfusion/ts/documents/tn18235.htm).
But even then, the use of CFLOCKs to prevent those race conditions is still
NOT really single-threading the execution of the code in the lock--at least
with respect to code doing no lock at all.
CFLOCK doesn't lock access to a scope, or access to a tag, or (especially
not) access to a database.
It is simply a request for programs to play nice with each other. If a
program chooses not to "play nice" (uses no locks), there's really nothing
that can be done to avoid concurrency issues.
/charlie
> -----Original Message-----
> From: Alan Ford [mailto:[EMAIL PROTECTED]
> Sent: Saturday, August 16, 2003 3:21 AM
> To: CF-Talk
> Subject: cflock - what does it do? Exactly?
>
>
> I've seen <cflock scope = "session" type = "exclusive">
> described in two ways in the documentation (and I have my
> own, different, understanding of
> it) - I'd be interested to know which one is true.
>
> a) It holds the only exclusive lock for that session. Any
> other code for the session can run; the only thing that will
> be stopped is another attempt to take a session lock (either
> exclusive, or read-only) [my own intuitive understanding of cflock]
>
> b) 'An exclusive lock single-threads access to the CFML
> constructs in its body. Single-threaded access implies that
> the body of the tag can be executed by at most one request at
> a time. A request executing inside a cflock tag has an
> "exclusive lock" on the tag. No other requests can start
> executing inside the tag while a request has an exclusive
> lock. ColdFusion issues exclusive locks on a first-come,
> first-served basis' [mm website -
> http://livedocs.macromedia.com/coldfusion/5.0/CFML_Reference/T
ags57.htm]
So, if the lock contained <cfset> and <cfparam> statements then nothing else
in that session could execute a <cfset> or <cfparam> statement until the
exclusive lock was cleared
c) 'once inside a locked block of code, all other threads are queued until
the thread with the exclusive lock relinquishes control' [cfmx web
application construction kit]
Regards,
Alan Ford
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/lists.cfm?link=t:4
Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Get the mailserver that powers this list at
http://www.coolfusion.com
