The current discussion on locking, and what CF should do vs what the programmer should do, is really mixing two different issues. The concern that most of us have had for some time is not that we need to do locking to preserve application data integrity, but that we also need to do extra locking to preserve CF Server's memory integrity. The first is something that I think most of us would prefer to do ourselves, since we "know better than CF" where our own apps really need locking. It's the second case, where we are forced to lock down everything in sight because if we don't, then sooner or later the CF Server is going to roll over because it's memory management has serious problems.
I asked about this specific situation at the open session at Devcon2001, and Jeremy Allaire answered with the specific statement that this (the internal memory management locking problem) was fixed in Neo, and that all we would need to worry about in the future is locking to preserve our application's data integrity. My personal speculation is that the current memory management code is probably the Three Mile Island part of the server codebase, and that even though its problems have been well understood for years, no one has been able to muster up the courage to try and work on it without having the entire server go up in a mushroom cloud. With Neo they could just abandon it rather than fix it, and so the problems are taken care of. -reed FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
