Symptoms: error like this one

Thu Sep 17 11:31:05 2009] [error] [client 10.10.7.39] PHP Fatal error: Cannot redeclare ezurlwilcardcachedreqexparray() (previously declared in /home/ez_consumer/var/cache/wildcard/wildcard_d593c35623fe6ea667c103403a1b3d45_index.10.10.7.81.3936.1253183464.9515.tmp.php:9) in /home/ez_consumer/var/cache/wildcard/wildcard_d593c35623fe6ea667c103403a1b3d45_index.10.10.7.81.3936.1253183465.0143.tmp.php on line 11,

Analysis:

• oracle db cluster layer tries harder than the mysql one to create a UNIQUE file on the local fs when asked to: it uses the timestamp+pid+server IP, as compared to simple pid on the mysql side

• the current urlwildcard code seems to act like this: every time a call to translate() is made, the following calls are made:
  translate()
  setupMatchCallbacks()
  loadCacheIndex()

The funny thing is that loadcacheIndex() does not check at all to see if the cache index file had been included in the past - it just creates a temp copy of it from the db into the local fs, runs include_once() on it then deletes it.

As far as I can tell, this works on mysql because if you run the translate() call twice, you will end up creating on the fs twice a temp file with the same name, and php will not include it again the second time (even though its contents might actually have changed).

The good question is thus: is it a good idea to run this copy-file-from-db-to-fs-include_once-it-then-delete-it many times over?

I think that once we have included it, we should avoid doing all of this work again - we should just store the two callback arrays in static class vars on first load, and check if they're there in setupMatchCallbacks() before doing the loadCacheIndex() call...
...anyway this has already been fixed in 4.2, where the wildcard cache has been overhauled. Bug applies to 4.0 and 4.1 (but 4.1 has no support for cluster mode yet)