Could Not Unlock The Names Lock "GOOGLE.TXT" Because No Lock Is Known By That Name
Posted January 30, 2007 at 7:38 AM by Ben Nadel
I just had this error sent to me:
Could not unlock the named lock GOOGLE.TXT because no lock is known by that name.
I have absolutely no idea what this means. When I look at the chunk of code that seems to have triggered it, given the stack trace and ColdFusion tag context, it seems it was this CFLock tag:
- file="#GetDirectoryFromPath( GetCurrentTemplatePath() )#google.txt"
But what about that could cause the error? And why would ColdFusion attempt to unlock a lock that had no name? I can only assume that the server was having a bit of trouble (hanging or about to shut down) and just "could not compute." The way I figure it, the only reason it would go to Unlock a lock would be in the close of a CFLock tag. However, if that was the case, surely the CFLock tag would know its own name??? Very curious.
Here is some of the stack trace if you are interested:
coldfusion.runtime.LockManager$UnknownLockException: Could not unlock the named lock .....GOOGLE.TXT because no lock is known by that name. at coldfusion.runtime.LockManager.releaseNamedLock(LockManager.java:89) at coldfusion.tagext.lang.LockTag.doFinally(LockTag.java:209) at cfApplication2ecfc1429649158$funcONSESSIONSTART.runFunction
What Other People Are Searching For
- Wanted: Full-Time ColdFusion Developer at Intoria Internet Architects
- Cold Fusion Senior Developer at Edge Information Management
- Back-End Web Developer-Information Technologist at Michigan State University
- ColdFusion Developer at Nonfat Media
- Mid-to-Senior Level Web Application Developer at SiteVision, Inc.
Is this code recently written? the name google.txt seems strange to me, only because it possibly may be that cf is thinking that is a variable of some sort?
Does it error every time, or just once in a blue moon?
first thing that strikes me is the use of a "." in the name, maybe its causing a problem. I know it should be a string but maybe under the hood in java its freaking it out.
google has a cached version of this error. Doesnt look like the "." is the cause as this guys lock has a different name
I should google before adding comments!
heres the answer
should be i a hot fix by the sounds of it