> Which is exactly why you have to be consistent with locking. ;^) I don't see how consistency directly relates to what I was talking about. Modular code generally knows very little about its context: that's the whole point. You can be entirely consistent and still end up with deadlocks if one piece of code isn't aware of what's going on around it.
> Generally nesting concerns would only happen with scope level locking or > site-wide name-level locks. The names used in "name level locks" are completely arbitrary. What happens when you call a third party CFC that just happens to use the same name that you use? Better yet, what happens when your cfc, which locks the session scope, accesses a singleton registry which locks the application scope? > 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). You're assuming you have access to and an intimate knowledge of all the code in question. I used a third party CFC in a recent project. It's encrypted, so I have no idea what locks it might create, what scope they are or what it names them, etc. We used the Component Kit in another project. That stores quite a bit of information in the server scope of all places. How did that information get there? > 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. All failures are a failure of design. :) The point I was trying to make is that you have to know a good deal about locking and how your code will be used to lock properly. Otherwise, you end up deadlocks instead of race conditions. The end result is the same: inconsistent data. Consequently, I don't believe that the "lock everything" paradigm is any better than not locking at all. > 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. This is clearly something we disagree on. I'm sure I'm biased because I've seen far more deadlock issues than race conditions. > 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. If the novice is locking everything, then deadlocks are sure to ensue. ColdFusion does nothing to prevent the loss of data integrity in a deadlock situation. > 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. ;^) Yes, but short of that, I would not recommend "locking everything". I would recommend the opposite: do not lock unless you have a reason to. > 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. And you've probably had very few deadlock issues. I do the same. I generally have a handful of well named locks in any application. I've had very few deadlock issues and, in almost a decade of Web programming, I can probably count the number of race conditions I've seen on one hand. > 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.) I know what you mean. It's always when I'm most sure of myself that I'm the furthest from being right. :) I actually had to write my own locking routines in ASP a couple of years ago. ASP lacks anything analogous to the cflock tag. To make a long story short, I discovered the hard way that locking was a far more intricate and delicate process than I had thought. I came back to ColdFusion with a new found respect for locking issues. Ben Rogers http://www.c4.net v.508.240.0051 f.508.240.0057 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net http://www.cfhosting.net Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189088 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
