> I'm not sure how this relates in CF... > > The only real way that I know of to get a real deadlock in CF is to nest > lock requests. Like the following: > > <cflock scope="Application" ...> > <cflock scope="Session" ...> > </cflock> > </cflock>
As far as I know, it's only possible via nested locks. There's actually a good deal on deadlocks in the ColdFusion documentation: http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/shared52.htm http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/shared52.htm > And even then is only a real problem if you are inconsistent with the > nesting order of the lock requests. 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. > I don't think CF does anything > special about this however - the templates just timeout normally unable > to finish their work. I think you're correct. In fact, I was trying to argue that the problem is that ColdFusion does not recognize deadlocks like an RDBMS would, for instance. ColdFusion can't detect a deadlock situation, choose a deadlock victim, and rollback the changes that that script has made. > 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. > 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. 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. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - New Atlanta http://www.newatlanta.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189082 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=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
