Well, yes, if it is the same var you would want the same name... Sorry. But if you have session.longprocess, and session.shortprocess then you would want to use names on your locks, but wherever you have session.longprocess you would use the same name...
Jason CFDynamics.com > -----Original Message----- > From: Smith, Matthew P -CONT(DYN) > [mailto:[EMAIL PROTECTED]] > Sent: Monday, September 23, 2002 1:07 PM > To: CF-Talk > Subject: RE: cflocking de-mystified (was RE: WHYYYYY!!!!!!) > > > > But if you access two variables in the same scope(ie session) > at the same time because of different names, can't that cause > corruption? > > Also, readonly locks are simply pointers; the only time they > are locked down is during an exclusive lock as used during a write. > > Matthew P. Smith > Web Developer, Object Oriented > Naval Education & Training Professional > Development & Technology Center > (NETPDTC) > (850)452-1001 ext. 1245 > [EMAIL PROTECTED] > > > >>-----Original Message----- > >>From: Jason Egan [mailto:[EMAIL PROTECTED]] > >>Sent: Monday, September 23, 2002 12:06 PM > >>To: CF-Talk > >>Subject: RE: cflocking de-mystified (was RE: WHYYYYY!!!!!!) > >> > >>Right - I use the name attribute for cflock rather than scope > >>(occasionally) because my understanding is that when you > lock on the > >>scope you Lock the entire scope down for that transaction -- if you > >>use names, then they are all (potentially) unique and you > won't have a > >>usually fast process waiting on a slow process - > essentially denying > >>client access because of scope locking... > >> > >>Jason > >>CFDynamics.com > >> > >>> -----Original Message----- > >>> From: Tony Weeg [mailto:[EMAIL PROTECTED]] > >>> Sent: Monday, September 23, 2002 7:53 AM > >>> To: CF-Talk > >>> Subject: cflocking de-mystified (was RE: WHYYYYY!!!!!!) > >>> > >>> > >>> > >>> my man, My Man! > >>> thank you dave. > >>> > >>> that's probably the funniest thing I have read this > morning and the > >>> most informative email I have gotten in a long time in regards to > >>> locking (kinda wish I'd made it to the locking > >> > >>> session last year @ devcon) > >>> > >>> but anyway, it makes sense, plain and well done. > >>> > >>> thank you! > >>> > >>> ps...i implemented this into my code @ my office @ my > real job this > >>> morning, and things are humming along.... > >>> > >>> now, I guess my next question would be, is the cflock > timeout sort > >>> of an arbitrary guess as to what would be a good amount > of time? I > >>> mean, how long are the lock timeouts on the heaviest hit cf pages > >>> set for? whats a good number? > >>> > >>> ...tony > >>> > >>> Tony Weeg > >>> Senior Web Developer > >>> Information System Design > >>> Navtrak, Inc. > >>> Fleet Management Solutions > >>> www.navtrak.net > >>> > >>> 410.548.2337 > >>> > >>> > >>> -----Original Message----- > >>> From: Dave Watts [mailto:[EMAIL PROTECTED]] > >>> Sent: Monday, September 23, 2002 1:52 AM > >>> To: CF-Talk > >>> Subject: RE: WHYYYYY!!!!!! > >>> > >>> > >>> > i havent used locks on session vars, havent > >>> > needed to, and having never formally learned > >>> > cf, not really 100% down with the thought > >>> > process behind locking session var setting... > >>> > >>> The thought process is very simple. If you're running CF 5 or > >>> earlier, and you're using session variables, and you don't lock > >>> them, bad things will happen. Memory variables can be accessed by > >>> concurrent requests, and CF doesn't handle that well, by default. > >>> While you might not think session variables would be used by > >>> concurrent requests, there are many possible cases in which more > >>> than one request from the same user might be running concurrently. > >>> > >>> > any good books on that topic? > >>> > >>> A book would be overkill, just for this topic. If you're > using CF 5 > >>> or earlier, just follow these simple rules: > >>> > >>> 1. Dvery time you put "Session", "Application" or > "Server" in your > >>> code, use CFLOCK around it. > >>> > >>> 2. If you're using any version of CF which supports the SCOPE > >>> attribute (4.5+, I think), use that with your CFLOCK tags around > >>> memory variables. > >>> > >>> 3. If you're reading a memory variable, use > TYPE="READONLY" in your > >>> CFLOCK; if you may change the variable's value, use > >>> TYPE="EXCLUSIVE". > >>> > >>> 4. There is no rule 4. > >>> > >>> 5. Reread rule 1. > >>> > >>> Dave Watts, CTO, Fig Leaf Software > >>> http://www.figleaf.com/ > >>> voice: (202) 797-5496 > >>> fax: (202) 797-5444 > >>> > >>> ::::::::::::: dream :: design :: develop ::::::::::::: > >>> MXDC 02 :: Join us at this all day conference for > >>> designers & developers to learn tips, tricks, best practices and > >>> more for the entire Macromedia MX suite. > >>> > >>> September 28, 2002 :: http://www.mxdc02.com/ > >>> (Register today, seats are limited!) > >>> :::::::::::::::::::::::::::::::::::::::::::::::::::::: > >>> > >>> > >>> > >> > ______________________________________________________________________ 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/[email protected]/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
