Many session-based sites run well without any cflocks but they're smaller sites.. It doesn't seem to me to be a policy of knowing what your doing or not, its more about the fact that you don't ever want data mixed up, ever.
To me its worth a few more lines of code to always protect my user's data. I can see where locking or not locking application variables could be harmless but I stand firm on sessions needing to be locked. On Fri, 31 Dec 2004 16:52:00 -0500, Jim Davis <[EMAIL PROTECTED]> wrote: > > -----Original Message----- > > From: Ben Rogers [mailto:[EMAIL PROTECTED] > > Sent: Friday, December 31, 2004 4:28 PM > > To: CF-Talk > > Subject: RE: Well - I feel like an idiot. > > > > But what happens if you call a UDF, CFC method or custom tag within a > > lock? > > Each of these provides a degree of encapsulation, meaning you don't know > > what they might be doing. > > Which is exactly why you have to be consistent with locking. ;^) > > Generally nesting concerns would only happen with scope level locking or > site-wide name-level locks. In those cases, despite the encapsulation of > extensions you'll need to know something about the application architecture > to create them in first place (I think). > > > > In other words I don't believe CF has the concept of deadlock victims, > > but > > > I could be wrong. As far as I can tell when a lock request times out, > > > it's dead - it either skips the locked code (being unable to obtain the > > > lock) or ends the template with an error (depending on how you set up > > the > > > lock request). > > > > I used the term "deadlock victims" in the first paragraph to mean the > > templates were victims of a deadlock situation, not that ColdFusion had > > determined that they were deadlocked victims and treated them as such. > > Sorry for the confusion. > > No problem - this is just a topic I'm very interested in. > > > > I'm way too tired to consider this clearly, but I'm not sure I see the > > > potential for a deadlock where "some" locked code is run and would need > > to > > > be "rolled back" (I'm not sure how you would roll back arbitrary code > > even > > > then). > > > > The issue with race conditions is that you end up with data that's in an > > inconsistent state. If you have two templates that get terminated because > > of > > a deadlock situation, both templates could have updated some information, > > but not all. In other words, the end result of a race condition and a > > deadlock is the same: inconsistent data. > > True - but that would be a failure of design, not of locking. If your > template is doing something outside of locks that would affect code inside > of locks like that I would think you'd need to reevaluate how you're doing > things. > > > Instead of a race condition (which can often be harmless), you caused a > > deadlock. Neither process finished. Some data reflects the state before > > each > > template ran. Some data, after. With a deadlock, the user gets an error in > > the process. > > That depends - but I agree in theory. I still stand by my belief that > locking is safer than unlocking if you don't know what you're doing. > > In most cases data integrity is more important than experience and since > nested locks are the only way to create a deadlock in CF it seems to me rare > that a novice would encounter the issue. > > Of course I think we both can agree that the preferred thing is to actually > gain an understanding of threaded requests and locking before writing a CF > application. ;^) > > In practice I actually write much more like you're talking about: very few > locks. Since I know (or at least think I know) what's what I feel confident > in choosing when to an when not to lock. > > Then I get bitten in the ass by something the code that I started the thread > with. ;^) (I know that wasn't really a locking issue per se, but it's > definitely in the ballpark.) > > Jim Davis > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - RUWebby http://www.ruwebby.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189086 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
