Thanks Geoff. I've put locking around the reads of the critical session variables. I haven't been able to reproduce the problem myself, so I'll wait and see if it reoccurs.
Phil. ----- Original Message ----- From: "Geoff Bowers" <[EMAIL PROTECTED]> Newsgroups: cfaussie To: "CFAussie Mailing List" <[EMAIL PROTECTED]> Sent: Thursday, January 23, 2003 12:26 PM Subject: [cfaussie] Re: Automatic Read Locking > Phil Evans wrote: > > Just to clarify - I have a cfmx app which locks updates to session > > variables, but not reads of session variables. > > There is some occassional strange behaviour where it appears that the > > session variables are pointing to the wrong customer. > > This could be one of the symptoms of memory corruption (Unexpected shared > > scope variable evaluation results), > > or just a programming bug I need to resolve. > > > > From what you've said, under CFMX I can definitely rule out memory > > corruption as a potential cause. > > Memory corruption is not the same as data corruption. When it occurs in > CF5 it invariably leads to server failure. I should note that this is > not a CF thing - it's a C++ thing. Java handles this type of condition > differently. > > The race condition may lead to data corruption such that the variable > you are referencing may return inaccurate data. This is rare in session > based variables unless your server is under heavy load, you are using > framesets, or your user might be inclined to run multiple browsers to > view your application. > > > Also, can you define "race conditions" for me? > > From Whatis.com: > "In computer memory or storage, a race condition may occur if commands > to read and write a large amount of data are received at almost the same > instant, and the machine attempts to overwrite some or all of the old > data while that old data is still being read. The result may be one or > more of the following: a computer crash, an "illegal operation," > notification and shutdown of the program, errors reading the old data, > or errors writing the new data. This can be prevented by serialization > of memory or storage access, such that if read and write commands are > received close together, the read command is executed and completed > first, by default." > http://searchstorage.techtarget.com/sDefinition/0,,sid5_gci871100,00.html > > -- geoff > http://www.daemon.com.au/ > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > > MX Downunder AsiaPac DevCon - http://mxdu.com/ > --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
