Why does a feature of CFLOCK seem like a bug?

[Guest]

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!

[Grizzly9279]

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!

[Guest]

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...?

[Grizzly9279]

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">

[Newsgroup_User]

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

[Guest]

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.

[Newsgroup_User]

Something to add to your tests is something documenting what session is
running each request. Your assumption is that opening a new browser
window is accessing the same session. That is not guaranteed to be
true. It can happen but it may not happen for many different conditions.

So I would first make sure the second request did not run in a different
session and thus had no allegiance to the session lock being held in the
first session.

[Guest]

Thank you for contributing to this thread. Any advice or
thoughts you have is greatly appreciated.


> Something to add to your tests is something documenting
> what session is running each request.

I failed to mention that subsequent to my initial posting,
I have modified my simple program to do just as you
suggested. I have been testing with #session.SessionID# in
the code and can confirm that both windows are displaying
the same session id.

I have also confirmed that the sessionid is not changing when
I hit ctrl-f5 (several times each in both browsers).

I have also added a counter variable in the session scope
to confirm that either browser can increment the counter
and that both browsers correctly increments and displays
the next value.


> So I would first make sure the second request did not run in
> a different session

I am 100% sure both browsers are using the same session because
both browsers display the same sessionid and is able to increment
the same session variable.


I am now starting to believe that I'm not the only who
believes that <cflock scope="session" type="exclusive" ... >
SHOULD cause other requests under the same session to
be blocked in order to allow "single-thread access to
the CFML constructs in its body".

However, I'm still holding out hope that there is no bug
here and I'm simply not understanding why this abnormal
behavior is necessary/desired.

Once again, I thank you for your patience and stamina for
reading this post to the end.

[Newsgroup_User]

i have tried to replicate your tests and DO NOT see the behaviour you
are seeing.

of course, the testing environments may be different...

tested in both cfmx 7 and cf8 [installed on same laptop]
in ff2 browser (opening new tab instead of new window to ensure session
is preserved)
both cf servers are set to use J2EE sessions
i have added name='cflocktest' in the <cfapplication> tag in your code

what i am seeing is:
- when the url.work var is defined, the page takes about 300 times
longer to load than without that var in url on both systems
- the second tab dutifully waits 30 seconds for the first tab to release
the lock

i will try to test with regular sessions on more browsers later, but
somehow i do not think i will see your results...

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

[Guest]

Thank you so very much for taking the time
look into the issue I am having.


> of course, the testing environments may be different...

I too have tested on CF7 and CF8. For me,
the behavior is the same on both environments.

However, my previous sample code required some
changes before it could be used for testing.

I have attached a new sample code that does
not require any changes but yet will still
illustrate the behavior I have described.

Also, here are the ten steps I took to observe
the behavior:

1) Open a browser and go to http://localhost/test.cfm?work=false
2) Hit ctrl-n (to open second browser)
3) Confirm that both browsers display the same session id
4) Hit ctrl-f5 a few times while alternating browsers
5) Confirm that session id is not changing and counter is incrementing
6) Note the counter values in browser one and browser two
7) In browser one, change the url param from work=false to work=true
and hit the Enter key
8) In browser two hit ctrl-f5 once and notice that it returns right away
9) Hit ctrl-f5 in browser two a few more times and watch the counter go up
10) In browser one, wait for page to return and notice the counter value


For my particular run of the test, at step 6,
browser one had a counter value of eight and
browser two had a counter value of five.

By step 10, my browser one's counter value
was now fifteen.

How could the counter have go up from 8 to 15
if browser one had an exclusive lock?

In other words, why does step 8 and step 9
return right away with an incremented counter
value if in step 7 browser one obtained an
exclusive lock?


Here's the new sample code. Save it as test.cfm.

You do not have to make any modifications.

I am glad to hear that you are not experiencing what
I have observed. Perhaps this new sample code
and test script can serve as a baseline for others
who want to participate.

Thank you again for your efforts.

[Newsgroup_User]

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/

[Guest · Accepted solution]

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

[Newsgroup_User]

yes, i knew it would be that! :)

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

[Newsgroup_User]

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

Well it *is* documented as being required if one wishes to use session
variables: http://livedocs.adobe.com/coldfusion/8/Tags_a-b_5.html

That said, it would be nice if having the sessionmanagement attribute
without a name attribute caused an error.

Now: for my strange behaviour.

When *I* run your code (or a variation in which it's easier to see what's
going on and when) on Firefox, Firefox seems single-threads the requests
completely, ie: the first line of code (which in my version outputs a
timestamp) of request 2 does not execute until after request 1 completely
finishes. Not so if I run both browser sessions in IE, or - predictably -
a mix of the two.

If I run the test in Opera, then both windows *output exactly the same
results* (including timestamps!), despite the processes clearly being
kicked off at different times, due to me not being able to instantaneously
kick of each request in two different windows.

Although I put this down to screwiness on my PC.

--
Adam