Skip to main content
A
Anonymous
March 4, 2008
Answered

Why does a feature of CFLOCK seem like a bug?

  • March 4, 2008
  • 3 replies
  • 1468 views

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!
This topic has been closed for replies.
Correct answer
i have tried your new code, and in both cf7 and cf8, and both with
second page in new tab and new window, i got a lock timeout errors on
page 2...

Azadi Saryev
Sabai-dee.com
http://www.sabai-dee.com/


Thank you all for giving this topic consideration.

Alas the answer was due to my bad code.

Azadi's hint and persistence paid off.

The issue was due to my <cfapplication> tag NOT
having the REQUIRED attribute "NAME".

I was able to observe the desired behavior by
simply changing my new sample code to include
the name attribute in my <cfapplication> tag.


Thank you again to all who gave this post some
careful thought.


By the way, in CF5, the name attribute is a required
attribute. Post CF5 it is optional. After going
through six different environments with six different
configurations, I found a CF5 CD and installed it.

After removing the java-ish code, I promptly got
an error stating that the name attribute is a required
attribute... ouch.


Perhaps someone from Adobe's ColdFusion team
can make a change such that if the tag validator sees
this line of code...

<cfapplication sessionmanagement="true" />

the tag validator will throw an error stating that
the NAME attribute is missing.

Perhaps I should have titled this topic as:

Why does a feature of cfapplication seem like a bug?
when sessionmanagement=true and name attribute is missing

3 replies

N
Newsgroup_User
Inspiring
March 5, 2008
You don't actually say what you're seeing to suggest that it's not working
to spec. This would be a good place to start for people trying to work out
if there's an issue.

I've seen some "interesting" behaviour when running your sample code which
has given me pause for thought, but I don't see anything to suggest what
you're seeing.

but then again I don't know what your evidence is to suggest anything's
wrong, so it's hard to say.

--
Adam
A
Anonymous
March 5, 2008

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.

G
Grizzly9279
Participating Frequently
March 5, 2008
I'm really not sure, but if the session scope exclusive lock isn't doing what you would like it to do, you could always created a named lock using the session ids/tokens as dynamic inputs into the lock name.

Example:
<cflock name="namedLock1_#session.sessionId#" type="exclusive" timeout="30">
G
Grizzly9279
Participating Frequently
March 4, 2008
It is my understanding that an exclusive scope lock will simply force other readOnly locks (of the same scope) to wait until the exclusive lock is done doing whatever it is that it is doing. (this prevents "dirty" reads) And I believe it only really impacts code/operations that are specifically referencing memory locations in that scope. If you happen to have other code within the lock that has nothing to do with the scope, it may not single-thread itself at all.

If you really want to single-thread a block of code, the best way to accomplish that is with a named lock. I do not believe scope locks are intended to do that.

I hope this helps!


A
Anonymous
March 5, 2008
Thank you for responding.

> an exclusive scope lock will simply force other readOnly
> locks (of the same scope) to wait until the exclusive
> lock is done

I too thought this might be the case. I believe this is a
more correct behavior. But it appears that we are both
wrong. The readOnly is not forced to wait until the
exclusive lock is done.


> I believe it only really impacts code/operations that are
> specifically referencing memory locations in that scope

This statement does not appear to be congruent with livedocs
and the usage examples given in livedocs. Livedocs specifies
that the tag should be used "Around file manipulation constructs".


> If you really want to single-thread a block of code, the best
> way to accomplish that is with a named lock.

Right. My only issue with this approach is that the lock
is accross multiple users and/or multiple sessions.
Whereas I wanted single-threading per user/session.


Thanks again for responding. Perhaps there might
actually be a bug with the CFLOCK tag...?

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices