the ever popular cflock best practice revisited

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.

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.

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.

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

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

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

[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

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

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

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

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

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

>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

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