|WikiProject Computing||(Rated Stub-class, Low-importance)|
Shouldn't this be failure caching? From the article, it seems it doesn't refer to a cache failure, but rather, a failure cached... Evercat 02:48 26 May 2003 (UTC)
- Sounds that way. I've never heard of it, but maybe that's what they really call it... -- Wapcaplet 02:50 26 May 2003 (UTC)
Seems like it is a correct lingo among hackers. http://mail.python.org/pipermail/python-list/2001-November/071275.html
- Yeah hold on, that page uses it as a verb. But as a noun it's going to have to be reversed to make sense. When one engages in the practice of caching failure, one's program has failure caching. :-)
- (I haven't heard of it either, the above is just my interpretation of proper English...) Evercat 03:01 26 May 2003 (UTC)
I too have never heard of it, so maybe I am wrong. As you see, I just cut and pasted. -- Taku 02:56 26 May 2003 (UTC)
- I have heard of cache failure, which refers to the situation when something is requested which is not in the cache (such as when you get a web page that you haven't been to, or when the CPU asks for some memory that isn't in its cache). Failure caching would seem to me to be a more appropriate title for this article, but some quick searching on google hasn't turned up anything definitive. Is this a perl-specific concept? Maybe a perl guru could help us out. -- Wapcaplet 03:00 26 May 2003 (UTC)
- It's a pronunciation problem. Say "caching failure" rather than "caching failure". It is not a failure of caching, but a caching of failure. I hope my clarification helps. --FOo 06:36 26 May 2003 (UTC)
Have had exactly this, notably by caching connection strings in the COM+ Shared Property Manager (SPM). Problem is, after a DTC restart or package shutdown, the SPM corrupts / truncates entries stored in it (but doesn't delete the entry entirely). So next time we need a connection string, we pull out the corrupted one from cache. Resolution is to e.g. add a second entry in the cache, the second verifying the first (e.g. a MD5 hash or similar) - this way cache corruption can be detected and refreshed ... Not sure this is really antipattern ... ? (nonnb)
- It seems more like a bug than an anti-pattern. --Traal 22:04 06 Oct 2005 (UTC)
I agree with others who have stated that "caching failure" is a bad name for this article, as it is very ambiguous. "Caching failure" can be interpreted as if there was a process, caching, that had a failure. And yet, it can also be interpreted as a cache miss, when the cache failed to return a result and it has to be looked up from the original - while actually it's a cache hit, which is merely incoherent.
In the context of DNS, the term "negative cache" is typically used. "Failure cache" or "failure caching" also sounds more obvious than "caching failure". The lead section currently also states that it's a bug — while very often software might cache failures by design. -- intgr 11:15, 6 December 2006 (UTC)
I think this passage may be incorrect:
For instance, DNS requires that caching nameservers remember negative responses as well as positive ones. If an authoritative nameserver returns a negative response, indicating that a name does not exist, this is cached.
RFC 2182 (section 3.3) says "While positive DNS results are usually cached, the lack of a result is not cached." This is in regards to a nameserver's unreachability, though, not a response from a nameserver indicating a domain does not exist. So I'm not sure the above extract from the article is wrong. Perhaps sources/clarification could be added? --Pheelineerie (talk) 19:47, 5 March 2014 (UTC)
- Reading the context around that quote from the RFC, it seems to talk about a situation where the authoritative nameserver is unavailable entirely. But I'm not familiar enough with DNS to say either way. -- intgr [talk] 12:46, 6 March 2014 (UTC)
effective algorythms of negative caches?
effective algorithms for negative caches?