yet another locking ?

im a bit confused and after scouring through the archives and all my emails and the MM boards, I am left a bit confused. I'm running cfmx and I have seen that some people say that with cfmx that you don't need to lock your sessions at all and some say you need to lock everything. most of my sites wont need to be locked I'm assuming, small ones, mostly with just 1 admin user at a time. But I have several huge sites coming up (one of the reasons I am moving over to cfm) and the will have several hundred to over a 1000 people on at a time. I'm more concerned with the bigger sites obviously. I cant really find my answer in either book I am reading either (bens big ass, heavier than sh*t, already crushed my frickin foot with goliath! excellent book though!) and (the 10 steps book) btw~ both books need more pix! ha-ha so I wanted your guys recommendations Dave -------------- .::. -----------------------------------------

Dave, With CFMX you do not need to use CFLOCK on shared scope variables (session, application, server) UNLESS there is a chance of a race condition occurring. See http://users.evitech.fi/~tk/rtp/parallel-programming-theory.html#race_condit ion for a brief description of race conditions. Regards Stephen ----- Original Message ----- From: "Dave Lyons" <dave@dreamlofts.com> To: "CF-Talk" <cf-talk@houseoffusion.com> Sent: Thursday, February 06, 2003 1:38 PM Subject: yet another locking ? > im a bit confused and after scouring through the archives and all my emails and the MM boards, I am left a bit confused. > I'm running cfmx > and I have seen that some people say that with cfmx that you don't need to lock your sessions at all and some say you need to lock everything. > > most of my sites wont need to be locked I'm assuming, small ones, mostly with just 1 admin user at a time. > > But I have several huge sites coming up (one of the reasons I am moving over to cfm) and the will have several hundred to over a 1000 people on at a time. > > I'm more concerned with the bigger sites obviously. > I cant really find my answer in either book I am reading either (bens big ass, heavier than sh*t, already crushed my frickin foot with goliath! excellent book though!) and (the 10 steps book) btw~ both books need more pix! ha-ha

but when isnt there a chance of a race condition occuring. to me, on any HA site, you might have the opportunity for a race condition occuring.  things with computers, as I have learned over the years, are cut and dry 1's and 0', why can no one give us a definitive answer on locking shared scope variables? off I go into the wild locking yonder.....locking locking locking away :) ...tony Tony Weeg Senior Web Developer UnCertified Advanced ColdFusion Developer Information System Design Navtrak, Inc. Mobile workforce monitoring, mapping & reporting www.navtrak.net 410.548.2337 Dave, With CFMX you do not need to use CFLOCK on shared scope variables (session, application, server) UNLESS there is a chance of a race condition occurring. See http://users.evitech.fi/~tk/rtp/parallel-programming-theory.html#race_co ndit ion for a brief description of race conditions. Regards Stephen ----- Original Message ----- From: "Dave Lyons" <dave@dreamlofts.com> To: "CF-Talk" <cf-talk@houseoffusion.com> Sent: Thursday, February 06, 2003 1:38 PM Subject: yet another locking ? > im a bit confused and after scouring through the archives and all my emails and the MM boards, I am left a bit confused. > I'm running cfmx > and I have seen that some people say that with cfmx that you don't need to lock your sessions at all and some say you need to lock everything. > > most of my sites wont need to be locked I'm assuming, small ones, mostly with just 1 admin user at a time. > > But I have several huge sites coming up (one of the reasons I am moving over to cfm) and the will have several hundred to over a 1000 people on at a time. > > I'm more concerned with the bigger sites obviously. > I cant really find my answer in either book I am reading either (bens big ass, heavier than sh*t, already crushed my frickin foot with goliath! excellent book though!) and (the 10 steps book) btw~ both books need more pix! ha-ha

> but when isnt there a chance of a race condition occuring. > to me, on any HA site, you might have the opportunity for > a race condition occuring.  things with computers, as I have > learned over the years, are cut and dry 1's and 0', why can no > one give us a definitive answer on locking shared scope variables? > This is the definitive answer.   Its the same answer you'll get from Ray Camden, Simon Horwith, Christian Cantrell etc. Tony, I suspect that you may not understand exactly what a "race condition" is in terms of locking records and/or shared scope variables and would recommend looking up record locking in more detail.  I tried to find a decent article on this, but this : http://www.linuxfocus.org/English/September2001/article198.meta.shtml is the best I could find... Regards Stephen

well, your supposition is wrong :) sorry. I definitely understand a race condition.  what I don't understand is this: If a race condition could occur, even 1 time out of 1 hundred thousand iterations, isnt that enough to lock it?  I could imagine, if I had a shopping cart system, that I would EVER want someone to know what my CC info was, however, if a race condition is even somewhat a potentiality then even the smallest chance of occurrence is too much of a risk wouldn't you agree? btw, here is what I found about six months ago, and read to help understand this concept, its pretty helpful...there is also a java based graphic/animation simulation that explains this, and you can actually watch it happen...not sure of the url but here is the one I read.. http://www.cs.mtu.edu/~shene/NSF-3/e-Book/MUTEX/TM-example-philos-1.html ...tony Tony Weeg Senior Web Developer UnCertified Advanced ColdFusion Developer Information System Design Navtrak, Inc. Mobile workforce monitoring, mapping & reporting www.navtrak.net 410.548.2337 > but when isnt there a chance of a race condition occuring. > to me, on any HA site, you might have the opportunity for > a race condition occuring.  things with computers, as I have > learned over the years, are cut and dry 1's and 0', why can no > one give us a definitive answer on locking shared scope variables? > This is the definitive answer.   Its the same answer you'll get from Ray Camden, Simon Horwith, Christian Cantrell etc. Tony, I suspect that you may not understand exactly what a "race condition" is in terms of locking records and/or shared scope variables and would recommend looking up record locking in more detail.  I tried to find a decent article on this, but this : http://www.linuxfocus.org/English/September2001/article198.meta.shtml is the best I could find... Regards Stephen

> Yes, but then every use of a shared scope variable isn't necessarily going to generate a race condition. Simply checking for an application scope variable and setting it to a default value will not cause a race condition, because the value will always be the same.  Only if you're reading and then incrementing that application scope variable will you get a race condition. In your example of a shopping cart, locking was required in CF5 and lower because of other issues with session variables.  Using session variables in a CFMX application you are unlikely to get a race condition, unless you're using frames in the design of your site. You don't get a race condition if you're only reading a variable and not updating, so you don't need a lock. Stephen

cool. that makes sense...and from what I understand, it makes perfect sense, that macromedia planned around that, and did some homework for us. thanks! ...tony Tony Weeg Senior Web Developer UnCertified Advanced ColdFusion Developer Information System Design Navtrak, Inc. Mobile workforce monitoring, mapping & reporting www.navtrak.net 410.548.2337 Yes, but then every use of a shared scope variable isn't necessarily going to generate a race condition. Simply checking for an application scope variable and setting it to a default value will not cause a race condition, because the value will always be the same.  Only if you're reading and then incrementing that application scope variable will you get a race condition. In your example of a shopping cart, locking was required in CF5 and lower because of other issues with session variables.  Using session variables in a CFMX application you are unlikely to get a race condition, unless you're using frames in the design of your site. You don't get a race condition if you're only reading a variable and not updating, so you don't need a lock. Stephen

Just some additional interesting information on shared variable scopes:   the reason you do not need to lock them (unless you are attempting to   prevent a race condition) is that their underlying Java implementations   use java.util.Hashtables.  Hashtables are synchronized so that two   threads cannot modify the same instance of a Hashtable concurrently.   So Tony, you are right that Macromedia engineers did the right thing   here, otherwise there would be a lot more cflocking going on.  For   instance, if they had used a HashMap, all access/modification would   have to be locked (to prevent actual exceptions as opposed to just   unexpected behavior), which would make for a lot more code with no   advantages. Another thing to note is that synchronization at such a low level is   very fast and efficient; faster than using cflocks. Christian On Thursday, February 6, 2003, at 10:19 AM, Tony Weeg wrote:

so i take it the answer is no:) i did go read this tut http://www.vboston.com/depressedpress/content/coldfusion/guides/locking/5-us ingcflock.cfm bear in mind it looks to be written for 4.5 Dave -------------- .::. ----------------------------------------- ----- Original Message ----- From: "Christian Cantrell" <cantrell@macromedia.com> To: "CF-Talk" <cf-talk@houseoffusion.com> Sent: Thursday, February 06, 2003 11:06 AM Subject: Re: yet another locking ?

Dave, That article is relevant to CF4.x and CF5, but not CFMX Regards Stephen ----- Original Message ----- From: "Dave Lyons" <dave@dreamlofts.com> To: "CF-Talk" <cf-talk@houseoffusion.com> Sent: Thursday, February 06, 2003 4:22 PM Subject: Re: yet another locking ? > so i take it the answer is no:) > > i did go read this tut > http://www.vboston.com/depressedpress/content/coldfusion/guides/locking/5-us

yes, thanks i appreciate the effort though:) looks like quite a few people are confused on it. i can see tony now...unlocking...unlocking...unlocking lol Dave ----- Original Message ----- From: "Stephen Moretti" <stephen@cfmaster.co.uk> To: "CF-Talk" <cf-talk@houseoffusion.com> Sent: Thursday, February 06, 2003 11:49 AM Subject: Re: yet another locking ? http://www.vboston.com/depressedpress/content/coldfusion/guides/locking/5-us scopes: > > > the reason you do not need to lock them (unless you are attempting to > > > prevent a race condition) is that their underlying Java implementations a > > > > default value will not cause a race condition, because the value will

> -----Original Message----- > bear in mind it looks to be written for 4.5 It definitely was (I wrote it) - I'm doing the research needed to update it to MX now, but am getting a lot of "shoulds" and "most likelys" instead of "will" and "always" when I ask questions.  ;^) Jim Davis

But is still very relevant up to CFMX even though it was written relating to version 4.51 and written very well IMHO, thanks Jim. Here is an article from Macromedia regarding locking on ColdFusion MX. http://www.macromedia.com/v1/Handlers/index.cfm?ID=23021&Method=full Kind Regards - Mike Brunt Webapper Services LLC Web Site http://www.webapper.com Blog http://www.webapper.net Webapper <Web Application Specialists> It definitely was (I wrote it) - I'm doing the research needed to update it to MX now, but am getting a lot of "shoulds" and "most likelys" instead of "will" and "always" when I ask questions.  ;^) Jim Davis

http://www.duke.edu/web/cps001/labs/lab11/lab11.html is an applet, to actually watch it happen. ...tony Tony Weeg Senior Web Developer UnCertified Advanced ColdFusion Developer Information System Design Navtrak, Inc. Mobile workforce monitoring, mapping & reporting www.navtrak.net 410.548.2337 > but when isnt there a chance of a race condition occuring. > to me, on any HA site, you might have the opportunity for > a race condition occuring.  things with computers, as I have > learned over the years, are cut and dry 1's and 0', why can no > one give us a definitive answer on locking shared scope variables? > This is the definitive answer.   Its the same answer you'll get from Ray Camden, Simon Horwith, Christian Cantrell etc. Tony, I suspect that you may not understand exactly what a "race condition" is in terms of locking records and/or shared scope variables and would recommend looking up record locking in more detail.  I tried to find a decent article on this, but this : http://www.linuxfocus.org/English/September2001/article198.meta.shtml is the best I could find... Regards Stephen

> -----Original Message----- There's been a lot of talking about this and here's what I've gleaned (but not confirmed).  I'd like to confirm these however so I can update my Guide to Locking. 1) At the very least if you want to maintain possible compatibility with CF 5 or below you should agressively lock.  In most applications this isn't an issue, but it is for people that want to sell/distribute applications or tags that may be used in the older environments. 2) In CF 5 and earlier failure to lock would, under load, cause server corruption.  You'd crash the box, period.  In CFMX the scopes are thread-safe so you don't need to worry about taking down the server even if you never lock at all. 3) However, and here's the tricky part, although CFMX won't crash due to poor locking there's also no gaurantee that it'll return proper values. The internal locking (implemented in Hash Tables) is, as I understand it, much more "atomic" than CF 5.0. If, for example, you have two nested structures I think that one could be locked while the other isn't.  This means that you might read the "good" version of the child while the parent is being written (and, presumably before the child is written too). 4) Also the locking behavior for pointer-linked structs seems a little confused.  For example in CF 5 and below if you created a pointer to the session scope in the application scope you'd have to lock both scopes when accessing them.  (Although note that this is INCREDIBLY useful to see how many people are logged in and get access to their data!) I _think_ that you can safely ignore locking them in MX, but I've not gotten a definitive answer. 5) Reads definitely do not have to be locked in MX as they were in 5. For example in 5 you needed to lock the IsDefined() function - you simply don't in MX.  However unlocked reads may not return the data you'd expect in all situations. 6) Race conditions and transactional processing should still be locked ONLY to protect your data NOT (as was the case in 5) to protect the stability of the server. In the end the bottom-line seems to be that MX won't crash if you ignore locking, but it may not work the way you'd expect. Also remember that there are actually many ways in which race conditions can occur.  The obvious ones are Frames and multiple windows (whether programmed or user-launched).  However the Application and Server scopes are multi-thread accessed as a matter of course. Even with the session scope there are other ways.  Each resource on a page is called by a separate thread (for example if you have CF generated style sheets or Javascript files then they might run concurrantly with the main template).  Using FlashComm on a page can create multi-threaded accesses to the session as can something as simple as a user pressing a submit button multiple times. In my experience users opening multiple windows has been the biggest problem, but the submit button thing is another biggie. Anyways... Anybody have definitive answers/comments on the above points? Jim Davis

Jim, I'm not certain, but this looks like a race condition to me. Just a thought... Regards Stephen

> -----Original Message----- Sort of... But in 5.0 the whole shebang was considered a single unit (sort of).  So if the system automatically locks (as it does in MX) does it lock all members of a nested structure set when any of the members are accessed? In other words whether we call it a race condition or not, do we have to lock it? Jim Davis