Hello,

Back in September I posted a message regarding query cache key collisions<https://groups.google.com/d/msg/openbd/0Nmzg-eW0u4/GXMNIBSmDAEJ>.
Back then I was unable to reproduce the problem so that it could be
debugged properly, but since we are seeing more and more of these
collisions, I decided to bite the bullet and try and track it down.

Having found a good, somewhat traceable error, I was able to locate two
queries that collide. Incidentally both are using the CACHENAME attribute,
and one is using CACHEDOMAIN as well.

Here are two queries that cause a cache collision:

<cfquery datasource="#ds#" name="query1"
cachedwithin="#createtimespan(0,0,1,0)#"
cachename="getFeaturesForSpecificProduct_3447_18_english"
cachedomain="hardwareHighPriority">
    select 1 as one
</cfquery>

<cfquery datasource="#ds#" name="query2"
cachedwithin="#createtimespan(0,0,1,0)#"
cachename="specificSoftware-428-5483 Ratings spanish">
    select 2 as two
</cfquery>

CFDUMPing the query results easily verifies the collision:

<cfdump var="#query1#">

query [long version] one11Query Source:SQL (CACHE REFRESH)Datasource:DS
Query:select 1 as oneTime:1 ms
<cfdump var="#query2#">

query [long version] one11Query Source:SQL (FROM CACHE)Datasource:DSQuery:select
2 as twoTime:0 ms
Having taken a look at the OpenBD code for (query) caching, I don't think
there's anything wrong with the cache keys themselves, or the cache domain.
Unfortunately that's as far as I'm able to track the problem down.

Can anyone replicate the problem with the queries above? It doesn't seem to
be hostname related, since the same exact cachenames collide on all our
servers.

I would like to emphasize that the problem occurs also on queries with no
CACHENAME set. Actually avoiding these cache collisions is the reason why
we started adding cache names in the first place.

OpenBD version:

builddate    2012-01-01 10:14:17 GMT
edition    8
level    GPL
releasedate    1 January 2012
state    final release
version    2.0.2

Thanks in advance!

 Jari

Unless I'm mistaken, you don't need the cachedwithin parameter since the
cachename will cache the result until you will flush the cache.

In any case, what happens when you remove the cachedwithin part? Same issue
or solved?

I would have run into this many times, because we use cachename and
cachedomain extensively.

Kind Regards,
Nitai

Twitter - http://twitter.com/razunahq
Facebook - http://www.facebook.com/razunahq
Support Platform - http://getsatisfaction.com/razuna

Hi Nitai,

Thanks for your reply. Cachedwithin doesn't affect the problem - the
collision happens with or without cachedwithin defined.

Of course it depends on the app, but I don't think cachename obsoletes
cachedwithin. There are quite a few places where we want cache to expire
without explicit purging, but still want to retain the option to flush the
entire cachedomain if needed. The fact that <cfquery datasource="ds"
action="flushall" cachedomain="domain" /> flushes all queries, not just the
ones with cachedomain=domain, is a different matter.

FWIW, we are using a query cache of 8192.

Jari

Just bumping this up to check if anyone has tested the above case and
whether or not it causes a cache collision for them as well?

 Jari

good job Andy!

I'm curious what the problem that the fix fixed?
On Apr 17, 2012 2:27 PM, "Andy Wu" <a...@aw20.co.uk> wrote:

The cache name is normalized under the covers but in this case it was to
9 character key which was the same for quite different strings.

I've changed the normalization now so it's using MD5.

Andy

On 17/04/2012 20:32, Peter Farrell wrote:

Excellent! Thank you very much, Andy. That's what I suspected was going on.
Strange that no-one else had stumbled upon the issue before. Even with all
the caching (both query and compiled pages) we're hitting around 600 qps on
our MySQL backends, so I guess it took these types of loads for the bug to
rear it's head.

Again, thank you very much for fixing the issue. It has been plaguing us
for years - from the days of NewAtlanta's BD.

 Jari

Just wanted to confirm that the fix indeed solved the problem for us. No
collisions since I deployed the 2012-04-19 nightly build on all backend
servers last Friday.

Thanks again!

 Jari