DP Content DB vs Server Memeory CacheSubmitted by HawaiianDude on Thu, 02/04/2010 - 20:45
Set Geek Mode On
I have seen linking and page serving behavior that makes me think this:
There must be a content database behind the DP that physically stores content. - It never fails to load content when asked for content it has stored.
The storage Ids must be related to numbers like these:
Topic 123994 Reply 1331079
There is also a memory cache mechanisim working that plays a critical part of topic and reply creation and possibly topic reply page serving. This acts like a quick db in memory. (It is not a page content cache - it is like an in memory database.) This cache also participates somehow in topic and reply number storage.
This memory cache is displaying symptoms that would be similar to thread collisions - session collisions - lack of mutex - heap vs stack issues.
The symptom is like the memory cache does not know about some of the content ids used but it assumes it knows about all ids in use - as though it assumes it has an accurate cache of the content db id numbers - when in reality it does not have an accurate picture of the content DB id numbers. Certain operations fail becasue they rely on the innacurate cache - other ops always work because they always hit the DB content directly.
What is corrupting the cache. I assume the In memory cache uses a single key or a two value unique key pair to store information in the cache. For some reason data does not get to the cache correctly.
What I think is happening is this key or key pair is blank or null on one of its paramaters. What is trying to write a blank or null for one of the key values would be the real mystery.
super duper geek pure speculation and imaginary mode on
I saw a very very specific case that was similar once. It came down to the difference in the DB between these two statements.
CREATE UNIQUE INDEX (allow nulls) (but only one)
CREATE UNIUE CONTRAINT (no nulls)
The null - blank in the database allowed the code to get a valid db hit when in fact it was an invalid record with null as its PK value. So the cache code was intepreting a null as a valid hit becase the db told it was vlaid - but the code was intended to treat the blank null as bad. The db tricked the cache.