> -----Original Message----- > From: Dave Lyons [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 06, 2003 8:38 AM > To: CF-Talk > 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 > > so I wanted your guys recommendations
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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
