Hi Dennis, You still need to lock in CF 5 and as a best practice you should in MX. The difference between MX and 5 is that in MX the Java data structures used as scopes are designed to be thread-safe. For a better understanding of why you need to lock in version 5 and earlier I suggest you read Jim Schley's locking article (http://www.macromedia.com/v1/handlers/index.cfm?id=17318&method=full).
There was also a discussion about this yesterday too, if you go to this page: http://www.mail-archive.com/cf-talk@houseoffusion.com/thrd2.html scroll down to the CF Wishlist discussion, various posts are about locking in CFMX. Hope that helps, Christine -----Original Message----- From: UXB Internet [mailto:[EMAIL PROTECTED]] Sent: Friday, May 03, 2002 10:28 AM To: CF-Talk Subject: CF5 & MX Locking <cflock> Hello, At the risk of being charged with equine abuse, I just want to be sure that I understand the locking issue. Especially since every time I think I understand some one says something to change my worldview. We are still using CF 4.0.1 so I assume that locking to prevent memory corruption is required. In the attached message, Mr. Camden implies that at some version level, and I assume it is CF5 and CFMX, locking session, application and server variables to prevent memory corruption is _not_ required. However running code within an application in two browser windows, simultaneously, using the same session (same CFID/CFTOKEN) can cause unpredictable results when manipulating "memory variables" in the session and application scope. To further illustrate what I think he was inferring, assume that I had a page that took an input, did a query, and then added the query count to a session variable. I open two browser windows and supply different inputs to the same template in each window. Window 1: Session.x = 1 Input = a Query time = 5ms returns a value=5 Session.x=session.x + querycount Run separately he session.x value should be 6 Window 2: Session.x = 1 Input = e Query time = 15ms returns avalue=5000 Session.x=session.x + querycount Run separately the session.x value should be 5001 However if I run the template in the two browser windows simultaneously, where cfid/cftoken is the same, I _could_ get a result of session.x = 5006 in window 2 since window 1 finished first. Is this correct? It appears as if I have never _really_ understood the reasons behind the locking issue and only just the safety guidelines, so any and all help is greatly appreciated. Best regards, Dennis Powers UXB Internet - A Web Design and Hosting Company tel: (203)879-2844 fax: (203)879-6254 http://www.uxbinternet.com/ http://dennis.uxb.net/ -----Original Message----- From: UXB Internet [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 6:17 PM To: CF-Talk Subject: RE: CF Wishlist -----Original Message----- From: Raymond Camden [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 4:38 PM To: CF-Talk Subject: RE: CF Wishlist cflock is _not_ necessary for memory issues anymore. You still need it for logical reasons. For example: application.x = application.x + 1 Without locks, it's possible two threads could run the same code at once. Instead of x being x+2, it would be x+1. ======================================================================= Raymond Camden, Principal Spectra Compliance Engineer for Macromedia Email : [EMAIL PROTECTED] Yahoo IM : morpheus "My ally is the Force, and a powerful ally it is." - Yoda > -----Original Message----- > From: UXB Internet [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 01, 2002 4:25 PM > To: CF-Talk > Subject: RE: CF Wishlist > > > To stay on topic, and most likely cause more trouble, I on > the other hand > would like <cflock> to go away and not be necessary for > session, application > or server variables. It is my firm belief that variable > locking should be > part of the core CF engine and not part of the higher level scripting > language. Especially since it appears to always be required. > As much as I > understand the reasons for it's current existence in a multi-threaded > environment, <cflock> still has the appearance of being a > patch to a design > flaw. > > Best regards, > > Dennis Powers > UXB Internet - A Web Design and Hosting Company > tel: (203)879-2844 fax: (203)879-6254 > http://www.uxbinternet.com/ > http://dennis.uxb.net/ > > > -----Original Message----- > From: David Schmidt [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 12:42 PM > To: CF-Talk > Subject: CF Wishlist > > Ok, > > Have carefully considered what I want from CF, the most > striking feature I > want to see is... > > "Stop treating empty list items as null." That is a list of > "3,5,,,3,2,2" > should have a length of 7, instead of 5. Doing this would > nearly eliminate > the need for any field names like name="cost_#i#", since HTML > sends back > "3,5,,,3,2,2" for duplicate text fields named "cost" anyways. > > > > ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
