> -----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 - CFDynamics http://www.cfdynamics.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189084 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
