> I'm talking CFMX, and this example illustrates my point > exactly. The server > CAN'T do the job of CFLOCK for situations exactly like > this, so you (the > developer) have to use it, or some other locking > mechanism. Whether the > server protects it's own memory or not isn't a big deal, > it's whether the > values in memory are valid.
This is true -- although the situation with MX is the same situation faced by all programming languages. Race conditions are universal. So in the context of "what's the advantage of application vars in MX" that's why I say, you don't necessarily have to hound your shared scope variable with locking the way you did with CF 5 because in CF 5 and prior improperly locked variables had a way of being randomly corrupted so you'd wind up on sites with any reasonable traffic load where some user would have data from another guy's session, etc... But asside from that simply using a shared scope variable doesn't necessarily mean that you will have a race condition that will need to be locked against. For instance, if you set a session variable when a user logs in and then remove that session var when they log out, and in no other place in the app is that var modified in any way, then that var will likely never experience a race condition. But in CF5 and prior you still had to lock it anyway just because it's a session var. > --- > Barney Boisvert, Senior Development Engineer > AudienceCentral (formerly PIER System, Inc.) > [EMAIL PROTECTED] > voice : 360.756.8080 x12 > fax : 360.647.5351 > www.audiencecentral.com >> -----Original Message----- >> From: S. Isaac Dealey [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, April 01, 2003 4:21 PM >> To: CF-Talk >> Subject: RE: Is there a trick... >> >> >> I'm guessing that they actually mean "if your variables >> get hozed as a >> result of not locking it's happening because of a race >> condition >> of your own >> making". Rather than "data in the shared scopes may be >> randomly >> corrupted if >> not locked". For instance -- if you have a frameset that >> loads 2 >> frames and >> you need to set an application or session var before >> frame2 loads, but you >> set it in the template loading in frame1 there's a chance >> it might not get >> set until after frame2 loads and thereby frame2 would >> contain the >> wrong data >> -- but not through any fault of the server. This is >> probably a >> poor example, >> but at the moment it's the best I can do. :) >> >> > I interpret that paragraph as "The app server won't >> > dump >> > core if you don't >> > lock your shared access, but your variable might get >> > hosed." So, if you >> > don't mind your variables possibly getting wasted, then >> > yes, I'll agree that >> > locking is optional. >> >> > barneyb >> >> > --- >> > Barney Boisvert, Senior Development Engineer >> > AudienceCentral (formerly PIER System, Inc.) >> > [EMAIL PROTECTED] >> > voice : 360.756.8080 x12 >> > fax : 360.647.5351 >> >> > www.audiencecentral.com >> >> >> -----Original Message----- >> >> From: Matthew Walker >> >> [mailto:[EMAIL PROTECTED] >> >> Sent: Tuesday, April 01, 2003 3:27 PM >> >> To: CF-Talk >> >> Subject: RE: Is there a trick... >> >> >> >> >> >> Pretty sure. The docs: >> >> >> >> While the ColdFusion Server is thread-safe and does >> >> not >> >> try to modify a >> >> variable simultaneously, it does not ensure the >> >> correct >> >> order of access to >> >> information. If multiple pages, or multiple >> >> invocations >> >> of a page, attempt >> >> to write data simultaneously, or read and write it at >> >> the >> >> same time, the >> >> resulting data can be inconsistent, as illustrated in >> >> the >> >> following Sample >> >> locking scenarios section. >> >> >> >> It doesn't say "thread-safe except if you try to >> >> access >> >> application and >> >> server scopes". >> >> >> >> Yes you still have to lock them. But CFMX does it >> >> automatically, so you >> >> don't have to do it explicitly. >> >> >> >> >> >> >> >> >> > -----Original Message----- >> >> > From: Barney Boisvert >> >> > [mailto:[EMAIL PROTECTED] >> >> > Sent: Wednesday, 2 April 2003 11:17 a.m. >> >> > To: CF-Talk >> >> > Subject: RE: Is there a trick... >> >> > >> >> > Are you sure about this? It is my understanding >> >> > that >> >> > the session scope >> >> > was >> >> > protected automatically, but that the application >> >> > (and >> >> > server) >> >> scope still >> >> > had to be locked. You can avoid having to do read >> >> > locks with >> >> CFLOCK on a >> >> > scope if you ensure that they are never written >> >> > after >> >> > initially set, and >> >> > that every request ensures that they are set before >> >> > proceeding, but you >> >> > still have to lock them in one form or another >> >> > >> >> > barneyb >> >> > >> >> > --- >> >> > Barney Boisvert, Senior Development Engineer >> >> > AudienceCentral (formerly PIER System, Inc.) >> >> > [EMAIL PROTECTED] >> >> > voice : 360.756.8080 x12 >> >> > fax : 360.647.5351 >> >> > >> >> > www.audiencecentral.com >> >> > >> >> > > -----Original Message----- >> >> > > From: Matthew Walker >> >> > > [mailto:[EMAIL PROTECTED] >> >> > > Sent: Tuesday, April 01, 2003 3:00 PM >> >> > > To: CF-Talk >> >> > > Subject: RE: Is there a trick... >> >> > > >> >> > > >> >> > > Automatic locking. Previously you needed to write >> >> > > >> >> > > <cflock timeout="1" throwontimeout="No" >> >> > > type="READONLY" >> >> > > scope="APPLICATION"> >> >> > > [do something with app variables] >> >> > > </cflock> >> >> > > >> >> > > Many people got around this by simply copying the >> >> > > application >> >> > > scope into the >> >> > > request scope in Application.cfm or thereabouts. >> >> > > Others simply >> >> > > wrote lots of >> >> > > constants directly into the request scope on each >> >> > > page request >> >> > > (which isn't >> >> > > nearly as slow as you might think). >> >> > > >> >> > > With CFMX you don't need to lock access to scopes >> >> > > like application and >> >> > > session. >> >> > > >> >> > > > -----Original Message----- >> >> > > > From: Calvin Ward [mailto:[EMAIL PROTECTED] >> >> > > > Sent: Wednesday, 2 April 2003 10:47 a.m. >> >> > > > To: CF-Talk >> >> > > > Subject: Re: Is there a trick... >> >> > > > >> >> > > > Isaac, >> >> > > > >> >> > > > What's the benefit that CFMX offers in the >> >> > > > Application scope? >> >> > > > >> >> > > > Calvin >> >> > > > >> >> > > > <cf_snipalot /> >> >> > > > >> >> > > > > You'll be needlessly accessing the application >> >> > > > > scope anyway. The >> >> > > > application >> >> > > > > scope should really only be used for data >> >> > > > > which >> >> > > > > might change >> >> > > > periodically >> >> > > > > based on time of day, administrative >> >> > > > > interraction >> >> > > > > (i.e. "this >> >> > > feature is >> >> > > > > currently unavailable due to maintenance"), or >> >> > > > > to >> >> > > > > refresh >> >> a cacheing >> >> > > > > routine, etc. Data which is set, static and >> >> > > > > required on every page >> >> > > > should >> >> > > > be >> >> > > > > set solely in the request scope, unless you're >> >> > > > > running CFMX >> >> > > and planning >> >> > > > to >> >> > > > > access it directly from the application scope >> >> > > > > -- >> >> > > > > which I >> >> prefer not >> >> > to >> >> > > > do >> >> > > > > because imho there's no real benefit over >> >> > > > > using >> >> > > > > the request >> >> > > scope while >> >> > > > > there are definite advantages to using the >> >> > > > > request scope >> >> if you end >> >> > up >> >> > > > > needing backward compatibility for CF 5. >> >> > > > > >> >> > > > > hth >> >> > > > > >> >> > > > > >> >> > > > > s. isaac dealey 954-776-0046 >> >> > > > > >> >> > > > > new epoch >> >> > > > > http://www.turnkey.to >> >> > > > > >> >> > > > > lead architect, tapestry cms >> >> > > > > http://products.turnkey.to >> >> > > > > >> >> > > > > tapestry api is opensource >> >> > > > > http://www.turnkey.to/tapi >> >> > > > > >> >> > > > > certified advanced coldfusion 5 developer >> >> > > > > http://www.macromedia.com/v1/handlers/index.cf >> >> > > > > m?I >> >> > > > > D=21816 >> >> > > > > >> >> > > > >> >> > > > >> >> > > >> >> > >> >> >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > ~~~ >> > ~~~~~~~~~~~| >> > 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/uns >> ubscribe.cfm?user=633.558.4 > s. isaac dealey 954-776-0046 > new epoch http://www.turnkey.to > lead architect, tapestry cms http://products.turnkey.to > tapestry api is opensource http://www.turnkey.to/tapi > certified advanced coldfusion 5 developer > http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~~~~~~~~~~~| > 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 > Your ad could be here. Monies from ads go to support these > lists and provide more resources for the community. > http://www.fusionauthority.com/ads.cfm > Unsubscribe: http://www.houseoffusion.com/cf_lists/uns > ubscribe.cfm?user=633.558.4 s. isaac dealey 954-776-0046 new epoch http://www.turnkey.to lead architect, tapestry cms http://products.turnkey.to tapestry api is opensource http://www.turnkey.to/tapi certified advanced coldfusion 5 developer http://www.macromedia.com/v1/handlers/index.cfm?ID=21816 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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

