> -----Original Message----- > From: Andrew Mason [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 02, 2008 8:54 AM > To: cf-talk > Subject: CFLock deadlocking > > Hi Folks, > > I wonder if someone can help me. > > I have a situation where I use cflock when generating IDs to ensure no > duplications occur etc which 'sometimes' results in a deadlock > situation. > > <cflock timeout="8" throwontimeout="No" name="LockName" > type="EXCLUSIVE"> > <cfset ID=..........> > </cflock> > <Insert Query Here> > > Because the Throw is 'no' whenever the lock gets 'stuck' for whatever > reason (which is quite rare, but has a high impact negative outcome) > the timeout is ignored and then it carries on forever, or atleast until > I restart my webserver. It is important to keep the Throw set to No. > Does anybody have any suggestions as to what to do to break this > vicious circle of locking without any manual intevention?
I think you might be incorrect in your assumptions here... "throwOnTimeout" (as I understand it) only comes into play if the timeout was reached. And the timeout can only be reached if the lock was NOT OBTAINED during the wait period. A timeout occurs (meaning "I was unable to obtain a lock") and then, based on this setting, a decision is made to throw an error or continue as if nothing happened. In my experience it's very rare that you'd ever want to use "throwOnTimeout=no", but there are cases. If a deadlock has occurred it means that the timeout value was not met - the lock was granted. So both these attributes become meaningless once you're inside the lock. Deadlocks are caused when two processes require the same resources to continue but each process already has a hold on one of them. The classic example is two people that want to put on the same pair of pants: person A puts on the right leg and person B puts on the left leg and now their deadlocked. Both need the other's resource to continue and neither can finish until they get it. You need to focus on what resources are being tied and figure out how to extricate them. > The code above is actually an improved snippet than my earlier version > because I had previously included a select query and an insert query > inside the same bounding CFLOCK by the way. This may have been the > root cause of my problems because there was more work required in the > original lock code, but I don't really understand cflocks enough to be > sure. Very generally the more code that's in a lock, the "safer" that code is from deadlocks (after all, if all code were serialized then there could be no deadlocks) and the less code that's in a lock the more "dangerous" it is (the more likely two threads will deadlock). There are definitely a few generalities to look at with problems like this: +) A common problem is that the same resource is locked using different lock names or there are calls to the resource that are not locked at all. In this case two locks are fighting it out because both have a hold on the same resource. Do a catalog of all the locks in your app: do all locks for the same resource share the same name? Do the same for all accesses to the resource - are any not locked? +) Remember that CF can only lock code it's running. A database could have other applications (other CF apps, other application engines, etc), servers or admin tools requesting access that could affect CF as well. In other words try to remember that you're locking the code NOT the resource. (This is much more important when using direct Database lock however.) +) Beware (and understand) of "Exclusive" vrs "ReadOnly" locks. It's a common issue that some people face that they overuse exclusive locks or that they misunderstand read-only locks. For example in your code you might want to put that database read inside a "readOnly" lock. That lock should have the SAME NAME as the exclusive lock. This says "I can read this database only if nobody has an exclusive lock" and seems to be exactly what you want (but defiantly DO NOT nest the locks). > Maybe I could use an server monitor software to analyse a test CF page > which tries to run a lock with the same name and then runs some sort of > action to restart on it's own as a last resort? You might - but the problem, obtuse as it may be, should be completely addressable in code. But you really have to pick things apart from the point of view of "who is doing something with my resource and what access do they need?" Hope this helps, Jim Davis ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;207172674;29440083;f Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:313399 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
