Well, I guess is there are exclusive server scope locks like this one all over the place, you are basically single threading the entire server in multiple points, including all apps. Under the right load I suppose that could slow things down enough to start queueing threads and bring the server down, but that would require these locks all over the place, and for the load to be healthy.
If there are readonly/exclusive locks nested within each other all over, then that also introduces the possibility of deadlocks. So, yes, this could be part of a larger problem, but in and of itself it's pretty harmless. If there are lots of them, I'd remove the un-needed ones (probably virtually all of them if they are like this one) and see if that helps. However, if the original programmer did something this ridiculous, there probably a ton of other more damaging stuff in the codebase that's causing more serious problems. -Cameron On 8/31/06, Mary Jo Sminkey <[EMAIL PROTECTED]> wrote: > >That code doesn't have the power to crash anything, it's just dumb code. > > Are you sure? I'm wondering what that really long timeout is going to do. If > for any reason a thread isn't able to obtain a lock, it's going to be waiting > a *very* long time before timing out. I agree it's unlikely, but could be an > issue on rare occasions . ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:251720 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
