I can confirm this through pain. ;^) It's pretty obvious that requests are run in parallel when you two request calling the same method on an application-scoped CFC and they start to share loop iterators.
You can see this easily enough - create a CFC with a "Counter" method that just counts from, say, 1 to 100,000 and outputs the current number every 100 records. DO NOT use the var keyword for the index. Put that CFC into the application scope and run two requests (two different browser instances) against the method - you should see the counts go wonky. As an aside for this very reason I instantiate only one var variable in any method. At the top of the method I do: <cfset var Local = structNew()> Then I set all of my local vars in that struct - in effect creating my own "scope". It's a habit you have to get into, but helps immensely if you're having trouble remembering VAR. It also lets you create variables whereever you like in the method body (very useful if you ever CFINCLUDE your method bodies). Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Barney Boisvert > Sent: Friday, February 20, 2004 5:05 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race Condi > tions? > > Definitely not true. Requests are handled in parallel, which is why you > still need to use the local (var) scope and even CFLOCK on occasion. > > Cheers, > barneyb > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Roland Collins > > Sent: Friday, February 20, 2004 1:40 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] [Kind of OT]: Record Locking and > > Avoiding Race Condi tions? > > > > Don't forget that a multiple calls to the same method on the > > application > > scope are handled serially, which can have some rather large > > performance > > implications. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf > > Of Justin Balog > > Sent: Friday, February 20, 2004 4:12 PM > > To: '[EMAIL PROTECTED]' > > Subject: RE: [CFCDev] [Kind of OT]: Record Locking and > > Avoiding Race Condi > > tions? > > > > Lock manager would be in application scope, so I think it > > would go away > > to....right? Unless you meant to say that the servers stay > > up, but the > > clients go down. And I think that falls into my 2 concern? > > Still not happy > > with the idea, so all the feedback is good. > > > > Thanks, > > > > Justin > > > > -----Original Message----- > > From: Todd Rafferty [mailto:[EMAIL PROTECTED] > > Sent: Friday, February 20, 2004 2:09 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [CFCDev] [Kind of OT]: Record Locking and Avoiding Race > > Conditions? > > > > > > > > Justin Balog wrote: > > > > >I think there are a couple problems with this: > > > 1) Memory consumption. I think my having to load in > > all these obj > > >in the lock manager, you could potentially crash the server > > ---need some > > way > > >to control the amount of objects in the lock manager. > > > 2) User leaves open record with out committing to the > > save so the > > >open obj count in the lock manager would never be deincremented. > > > 3) I know there are going to be problems relating to RACE > > >conditions....so point them out!!!! > > > > > >Any thoughts, feel free to throw this idea up as you say > > 'PULL' and shoot > > it > > >down =) I am just starting to figure this out? > > > > > >Thanks again, > > > > > >Justin > > > > > > > > Freaky power glitch, all the the servers go down since they > > have battery > > backups. > > User A's connection drops. > > User B's connection drops. > > > > Lock manager says the record is still locked. How do you unlock it? > > What if their session times out? etc. > > > > ~Todd > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > > > ---------------------------------------------------------- > > You are subscribed to cfcdev. To unsubscribe, send an email > > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > > in the message of the email. > > > > CFCDev is run by CFCZone (www.cfczone.org) and supported > > by Mindtool, Corporation (www.mindtool.com). > > > > An archive of the CFCDev list is available at > > www.mail-archive.com/[EMAIL PROTECTED] > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail- > archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
