> The principles I spoke of in my post still apply, but CFLOCKs with > SCOPE="Session" only "key" to the one user's session now. ? > Named locks on code that access the Server or Application > scopes, or that try to safeguard non-threadsafe CFX tags by > single-threading access to them via named exclusive locks, > still work according to what I said earlier.
The way cflock worked with session locks in 6.0 did mean that you got locking contention when you weren't even thinking you should. Module A in session 1 would lock out module B in session 93, when there was no need at all to do that (aasuming that they both had exclusive session locks). On 6.1, and given a site that does not anticipate too much session contention (ie a site without frames and without Flash remoting) I don't think it's at all worth reengineering session locks to be named locks - do you? However, with a new app I can see distinct advantages to the technique of naming locks that you outlined in another post. Regards, Alan Ford ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Get the mailserver that powers this list at http://www.coolfusion.com
