Why does a feature of CFLOCK seem like a bug?

Question

I searched this forum for discussions about cflock
and read the livedocs at
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=sharedVars_20.html.
This reading is on top of me thinking I already knew
everything about using the cflock tag.
Apparently, I am not understanding a very critical
aspect of the cflock tag when locking the session scope.
My issue is regarding one user, one session, multiple
and concurrent requests arriving at the CF8 server
from the same user session.
Meaning, a web page that uses ajax, frames, pop-ups,
or the user hitting ctrl-n, will generate multiple
requests to the CF8 server using the same session.
Based on my understanding, using type="exclusive" will
effectively single-thread the access to code between
the lock tag. So my question is:
Why doesn't <cflock scope="session" type="exclusive" ...
>
single-thread the access to the code between the cflock
tag?
If you are kind enough to respond, I would really
appreciate an explanation why the current behavior
in CF8 is the more correct behavior. If the scope
is changed from session to application or server, it
will infact single-thread the access/execution.
So why is this not the case when the scope is session?
I arrived at this problem because I was trying
to explain to someone the difference between:
<cflock scope="session" type="exclusive" ... >
and
<cflock scope="session" type="readOnly" ... >
Based on my simple test and what I'm seeing, I discovered
I myself don't know the difference!
I know how to re-write the code to do exactly
what I want to do. I just can't seem to wrap
my head around why the cflock tag is implemented
this way (with respect to session and exclusivity).
However, it is more likely that I have a bug in my
simple test code...?
If you're interested, here's the code I used to
confirm/test my assumption:
Thank you for reading this post to the end!

Answer 1

Please be sure that I am very grateful that you both
are responding to my post. I am having difficulty
articulating exactly the issue since it may be a
feature of the CFLOCK tag and not a bug.
I thank you for being patient.
> You don't actually say what you're seeing to
> suggest that it's not working to spec.
What I'm seeing (with respect to the session scope
and exclusivity) is that the CFLOCK tag is not
behaving as documented in livedocs.
In particular, I'm referring to this statement in
livedocs:
"Exclusive - Allows single-thread access to the CFML
constructs in its body. The tag body can be executed
by one request at a time. No other requests can start
executing code within the tag while a request has an
exclusive lock. ColdFusion issues exclusive locks on
a first-come, first-served basis."
It occurred to me that it would be somewhat trivial
enough to prove this statement as being true. My
attached code was the beginnings of my attempt to
actually see single-threading at work.
However, what I actually observed was that this statement
from livedocs is actually false when using scope="session"
and type="exclusive".
Meaning, it did NOT "single-thread access to the CFML
constructs in its body".
> I don't see anything to suggest what you're seeing.
> ... I don't know what your evidence is to suggest
> anything's wrong
My attached code is the beginnings of an attempt to
gather some evidence. I was attempting to cause the
first request/browser to simulate a process that
takes 30 seconds. While the first request is performing
it's 30 second long process, I caused the second request/
browser to simulate a process that takes zero seconds
to perform.
My expectation was that the second request/browser will
not have an opportunity to begin processing since
the first request is holding an exclusive lock.
What I actually observed was that second request was
able to perform/continue without waiting or being blocked.
However, when I changed the scope from session to
application or server, I finally did observe the second
request waiting/being blocked. If I switch the scope back
to scope="session", the second request continues without
waiting/being blocked.
It is really hard for me to believe that there is a bug
here. I really do think that someone went out of their
way to allow this feature. I just wish I knew the rational
behind allowing this feature (and yet NOT documenting this
abnormal behavior in livedocs).
Thank you again for responding and taking the time to
modify and run my sample code (code must be modified
to experience the abnormal behavior). I did take note
of your mention that you experienced some "interesting"
behavior.