Hmmmm . . . is it possible to trust the documentation at all then? You are indeed correct - I just created a test script to prove it. But according to the CF Docs under "Selecting a function scope":
"Application Makes the function available across all invocations of the application. Unlike with functions defined in Application.cfm or included from other ColdFusion pages, all pages use the same in-memory copy of the function. Using an Application scope function can save memory and the processing required to define a function multiple times. However, Application scope functions have the following limitations: - You must lock the code that puts the function name in the Application scope, but you do not have to lock code that calls the function. - Application scope functions can cause processing bottlenecks because the server can only execute one copy of the function at a time. All requests that require the function must wait their turn. " I'm less and less confident in the cf docs every time I use them. -----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]
