Home of the ColdFusion Community
|
Mailing Lists
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
the ever popular cflock best practice revisited
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#165050
Here's a quick summary or status on the best practice of cflock use for session
variable for both preCFMX and CFMX based on this thread and the two articles from
MM site (correct me anyone you have new finding):
*) Rule of thumb: use SCOPE attribue with value of session for the whole
app(consistently) is safer than using NAME attribute in general or when in doubt.
*) Still no crystall clear/no definite answer as to "When to use SCOPE and When
to use NAME", a quote from one of MM's article on the subject, "Using the name
attribute is useful when you want a high level of granularity in your locking.",
it needs collaboration and case scenario.
And when it's determined that using NAME attribute is preferable to using SCOPE,
then when to use static/same NAME for a lock content and when to use dynamic lock
NAME becomes a question, quote from MM, "Note that you should never ever use
different names for locks on code that accesses the same data", implys that in
most cases, use static/same lock name, but part of of quote, "accesses the same
data" seem confusing, because normally, data within a lock may vary from users.
It would be a great value addition if MM clarify that.
----- Excess quoted text cut - see Original Post for more -----
Author: Matt Robertson
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#165026
Don wrote:
>I was given one very useful URL on cflock for preCFMX and a link to
CFMX
>http://www.macromedia.com/support/coldfusion/ts/documents/tn17882.htm#5
Yes, those both should tell you everything you need about cflock in both
pre- and post-MX environments.
This is a nice supplement for the pre-MX era:
http://depressedpress.com/DepressedPress/Content/ColdFusion/Guides/Index
.cfm
And has a good, fairly recent discussion on variables as well.
--------------------------------------------
Matt Robertson matt@mysecretbase.com
MSB Designs, Inc. http://mysecretbase.com
--------------------------------------------
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164993
>As a side note, cflock seams to be one of the most misunderstood elements of
>ColdFusion. There is not much information on it anywhere I looked. And when
>I find something it conflicts with information elsewhere. By far I am not an
>expert and don't spend my days looking at cflock, however, it would be nice
>if MM posted detailed specifications in a KB somewhere (last time I looked I
>didn't find anything).
I was given one very useful URL on cflock for preCFMX and a link to CFMX
http://www.macromedia.com/support/coldfusion/ts/documents/tn17882.htm#5
Author: Tom Kitta
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164973
I understand what Issac said in his post earlier, it makes sense that if
things work as he described then scope should be slower than name. However,
when I increased the loop counters by 10 and run from 3 different browsers
the prediction that Issac made don't check out. The browser that makes the
1st call is about even for name and scope. But the 2nd and 3rd show that
scope is 2 as fast as name. Now either there is still something wrong with
how I test it and one has to build a dedicated cflock testing system or we
still didn't get it.
As a side note, cflock seams to be one of the most misunderstood elements of
ColdFusion. There is not much information on it anywhere I looked. And when
I find something it conflicts with information elsewhere. By far I am not an
expert and don't spend my days looking at cflock, however, it would be nice
if MM posted detailed specifications in a KB somewhere (last time I looked I
didn't find anything).
TK
http://www.tomkitta.com
Tom and Issac,
An update:
Early this morning's testing with my client (total of 3 concurrent users
hitting same button/function simultaneously) seems to prove that
"locking session variables with SCOPE of session attribute and TIMEOUT
attribute value set according to an educated guess on the estimate of the
execution time of content inside a lock" WORKS WELL.
On "<cflock name="#createuuid()#">, my guess is, cf server (be it 5x or
6x) may treat "quasi variables", say, cflock with NAME attribute is one of
them, as variable class, then, according to CF spec, variable name may not
start with numeric value, then of course this type of NAMEd locking would
fail, while <cflock name="str#createuuid()#"> may be able to lock,
making sense? or do I need more coffee? Any MM cf server architecture
dude here? to confirm or clarify?
Don
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164970
Tom and Issac,
An update:
Early this morning's testing with my client (total of 3 concurrent users hitting
same button/function simultaneously) seems to prove that
"locking session variables with SCOPE of session attribute and TIMEOUT attribute
value set according to an educated guess on the estimate of the execution time of
content inside a lock" WORKS WELL.
On "<cflock name="#createuuid()#">, my guess is, cf server (be it 5x or 6x)
may treat "quasi variables", say, cflock with NAME attribute is one of them, as
variable class, then, according to CF spec, variable name may not start with
numeric value, then of course this type of NAMEd locking would fail, while
<cflock name="str#createuuid()#"> may be able to lock,
making sense? or do I need more coffee? Any MM cf server architecture dude here?
to confirm or clarify?
Don
----- Excess quoted text cut - see Original Post for more -----
Author: Matt Robertson
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164950
Don wrote:
>In sum, it seems applying cflock is part of best practice for both
preCFMX and CFMX.
Yes, it's a part of each but for different reasons. In CF5 on down, you
lock persistent scopes because if you don't you are taking your
application's life in your hands. As was said earlier, you can wind up
getting corrupt data in the form of shared session info, a flat-out
crashed CF service, waxy yellow buildup, ingrown toenails etc. All very
nasty.
In CF5 on down, you *also* locked to prevent race conditions; an
entirely separate circumstance. A simple example would be an
application variable that increments itself on each individual page hit:
<cflock scope="application" type="exclusive" timeout="10">
<cfset application.sitecounter=application.sitecounter+1>
<cfoutput>
This is page visit number #application.sitecounter# today.
</cfoutput>
</cflock>
You would lock the variable write and read to make sure that the user
saw the accurate page count, and not a number generated by someone else.
In CF 6+, the first of these two cases is no longer an issue, so
anything that was locked before *solely* for the sake of the first case
above no longer needs it. However, if you upgrade it won't hurt under
all but very extreme circumstances just to leave the locks in, so unless
you have a compelling reason... skip the anguish of recoding.
Further, if you have a race condition that is inconsequential, then you
can also dispense with locking. Using the example above, you as a
developer would have to ask yourself if you or anyone else really cared
if the display count was off by a tick or two. If the answer is no,
then you can get rid of that lock as well.
A more real world example would be a datasource name in the application
scope. Since it's the same globally, it doesn't matter if a race
condition occurs since the value is set only once in a while ... and
even if it wasn't, its the same value no matter what, anyway. Same deal
with a user session variable value that is only set once per session,
for example after someone logs in.
It feels very naughty to code in a naked
<cfquery datasource="#application.SiteDSN#" name="myItem">
...
</cfquery>
But its not going to hurt anything on MX.
--------------------------------------------
Matt Robertson matt@mysecretbase.com
MSB Designs, Inc. http://mysecretbase.com
--------------------------------------------
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164949
I love "mud", Issac, :)
I think you made some valid points. To create a cf lock like
<cflock name='session' ...> is totally and obviously senseless.
Don
----- Excess quoted text cut - see Original Post for more -----
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164947
Tom,
I'm re-writing that portion of other's code using SCOPE attribute of value
"session" for locking now to support concurrent users for the app.
Will test it to see result and update you and Isaac.
Thanks again.
Don
P.S.
"Incidentally I noticed a lot of people using createUUID()
for the named locks.", I think it's an easy misunderstanding that associates
CFLOCK with the normal concept of lock.
----- Excess quoted text cut - see Original Post for more -----
Author: S. Isaac Dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164944
----- Excess quoted text cut - see Original Post for more -----
The problem with this code as a test case isn't so much that you're
not using many variables, but that generally speaking, you're not
going to see the cflock actually doing anything in this case. It's a
single template, so everything within this single template is
single-threaded (within a given request) already. Unless you've got
several different browsers hitting that same page simultaneously, it
will perform almost as though no locking had been included at all (any
difference shouldn't be humanly noticeable). Differences in
performance between the named lock and the session lock will occur
based on the number of simultanous requests to (exclusively) lock the
given item. So because any of the scopes should preferably share more
variables (and be in heavier use) than a named lock (such as
getcurrenttemplatepath()), the scope locks when used will lock the
scope more frequently than a named lock, increasing the odds of two
requests to lock the scope occuring simultaneously. So the queue to
receive a lock on a scoped lock section fills up faster than the queue
to receive a lock on a named section (provided you've used a
reasonably specific name). The larger the queue, the longer it takes
to single-thread through all the requests for that lock.
Does this all make sense of have I made it as clear as mud? :)
> Incidentally I noticed a lot of people
> using createUUID()
> for the named locks. Wow, performance dies right there.
I don't know about peformance, but with <cflock name="#createuuid()#">
you may as well not lock at all, since each instance of the tag will
have a unique name, you'll never get any locking and your race
conditions will persist.
> You can run it yourself from:
> http://dev.energyshop.com/tk/mytest.cfm
> [Tom Kitta]
> I think it might also be a personal preferance.
Yes and no. As long as the application runs fast enough to not be
problematically slow then you're fine. If you find that an application
under load is running slow or certain sections are running slow, in
some cases you might find that switching from scope locks to name
locks or improving the names on certain locks can improve performance.
Though it's tough to define any hard-and-fast rules for handling
race-conditions.
s. isaac dealey 214.823.9345
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.sys-con.com/story/?storyid=44477&DE=1
Author: Tom Kitta
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164943
[Tom Kitta]
Well, as always in these situations I did a quick check as how things are in
the real life. Here is my code:
<cfset mm = GetTickCount()>
<cfloop index="m" from="1" to="10000" step="1">
<cflock timeout="30" throwontimeout="Yes" type="EXCLUSIVE"
scope="SESSION">
<cfset session.blob = 123>
</cflock>
</cfloop>
<cfoutput>Scoped: #GetTickCount() - mm#</cfoutput><br>
<cfset ww = GetTickCount()>
<cfloop index="m" from="1" to="10000" step="1">
<cflock timeout="30" throwontimeout="Yes" name="hfjdshfkshfks"
type="EXCLUSIVE">
<cfset session.bleeh = 123>
</cflock>
</cfloop>
<cfoutput>Named: #GetTickCount() - ww#</cfoutput><br>
I didn't see any performance differences. Maybe it is apparent with more
variables used? Incidentally I noticed a lot of people using createUUID()
for the named locks. Wow, performance dies right there.
You can run it yourself from:
http://dev.energyshop.com/tk/mytest.cfm
[Tom Kitta]
I think it might also be a personal preferance.
TK
The rule of thumb is that properly named locks will perform better
than scope locks, however, because you have complete control over the
names, named locks can perform worse than scoped locks if the name
provided is inspecific, i.e.
<cflock scope="session">
will probably perform better than
<cflock name="session">
(assuming the same scheme is used for locking the same events
throughout the application)
on the other hand
<cflock name="#getcurrenttemplatepath()#">
will perform _much_ better than
<cflock scope="session">
s. isaac dealey 214.823.9345
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.sys-con.com/story/?storyid=44477&DE=1
Author: S. Isaac Dealey
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164937
----- Excess quoted text cut - see Original Post for more -----
All requests with the same name, yes.
----- Excess quoted text cut - see Original Post for more -----
The rule of thumb is that properly named locks will perform better
than scope locks, however, because you have complete control over the
names, named locks can perform worse than scoped locks if the name
provided is inspecific, i.e.
<cflock scope="session">
will probably perform better than
<cflock name="session">
(assuming the same scheme is used for locking the same events
throughout the application)
on the other hand
<cflock name="#getcurrenttemplatepath()#">
will perform _much_ better than
<cflock scope="session">
s. isaac dealey 214.823.9345
new epoch : isn't it time for a change?
add features without fixtures with
the onTap open source framework
http://www.sys-con.com/story/?storyid=44477&DE=1
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164935
First, Tom, let me thank you for your knowledge and sharing. Please see my
follow-up below.
Don
----- Excess quoted text cut - see Original Post for more -----
In sum, it seems applying cflock is part of best practice for both preCFMX and
CFMX.
----- Excess quoted text cut - see Original Post for more -----
Thanks for the clarfication, good to know, in other words, when NAME is used
regardless of the value of NAME itself CF server applys "single thread" for all
requests.
----- Excess quoted text cut - see Original Post for more -----
I took your comment as SCOPE is preferable to NAME for performance sake, yes?
----- Excess quoted text cut - see Original Post for more -----
Agree as last resort. I intend to re-code all the session variable written by
prior developer for the app with SCOPE attribute of session, then run two testing
{sessions} with concurrent users with "Single Threaded Sessions" off and on.
I hope this course of action is the best option to circumvent the inherited
problem.
Again, thank you very much.
>
> Thank
you.
Author: Tom Kitta
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164934
I am a bit rusty on this topic, but this is all what I remember. If anyone
finds a mistake please correct me.
Hi,
I've inherited an app that does not lock session variables. The app runs
under CF5.0.
Have read cflock best practice for CF5.0. Here are a few questions:
(A) CFLOCK
1) heard that cf5 server and cfmx server handles cflock differently, so,
would cflock best pratice for cf5 applicable to cfmx if one day the app
upgraded to cfmx?
[Tom Kitta]
In CF5 locking was needed because all persistent scope variables
(session/application and server) could become corrupted if accessed at the
same time. Could even crash the server (or so theory goes). In CFMX thanks
in part to Java, this is no longer the case. However, you still need cflock
tag for the race conditions (rare occasions, but still does happen).
2) what about this notion of the NAME attribute, that is, a different lock
name would differentiate data/value inside a lock (be it read and write when
applicable), the analog of gym's lock room. No? with a SAME lock NAME, cf
server (5.0/prior and cfmx) would treat each request as students line up to
try that SAME lock with each one having a key/request in his/her hand?
[Tom Kitta]
The name is used when you don't actually lock the persistent scope
variables. The lock doesn't care what's in it, it just single threads all
requests.
3) given the fact that SCOPE and NAME attributes are mutually exclusive,
use one of them would suffice, so, the question is when to use SCOPE and
when to use NAME (data integriy number one task, less memory usage second
for either preCFMX or CFMX)?
[Tom Kitta]
Name is less used since it is not for session/application/server. You can
use it to say single thread file access for example.
(B) Single Threaded Sessions (CF Admin)
Could we construe that Single Threaded Sessions mechanism is a way that MM
designed to overcome the lousy coding of not locking session variables? By
that, I mean, so, instead of going through tons of code modification, just
apply the "Single Threaded Sessions" to let CF server to handle the locks
for data integrity. How well does "Single Threaded Sessions" does this job?
[Tom Kitta]
As far as I know this is last resort as it will slow down the server
considerably. I would not use it for production, maybe for debugging on
development server.
Thank you.
Author: Chunshen (Don) Li
Short Link: http://www.houseoffusion.com/groups/cf-talk/thread.cfm/threadid:32873#164931
Hi,
I've inherited an app that does not lock session variables. The app runs under
CF5.0.
Have read cflock best practice for CF5.0. Here are a few questions:
(A) CFLOCK
1) heard that cf5 server and cfmx server handles cflock differently, so, would
cflock best pratice for cf5 applicable to cfmx if one day the app upgraded to
cfmx?
2) what about this notion of the NAME attribute, that is, a different lock name
would differentiate data/value inside a lock (be it read and write when
applicable), the analog of gym's lock room. No? with a SAME lock NAME, cf server
(5.0/prior and cfmx) would treat each request as students line up to try that
SAME lock with each one having a key/request in his/her hand?
3) given the fact that SCOPE and NAME attributes are mutually exclusive,
use one of them would suffice, so, the question is when to use SCOPE and when to
use NAME (data integriy number one task, less memory usage second for either
preCFMX or CFMX)?
(B) Single Threaded Sessions (CF Admin)
Could we construe that Single Threaded Sessions mechanism is a way that MM
designed to overcome the lousy coding of not locking session variables? By that,
I mean, so, instead of going through tons of code modification, just apply the
"Single Threaded Sessions" to let CF server to handle the locks for data
integrity. How well does "Single Threaded Sessions" does this job?
Thank you.
|
May 24, 2012
|
Latest Fusion Authority Articles
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||
