I hope we finally have this issue licked.
Hopefully fix the stale site configuration issue.
Review Request #1449 — Created March 4, 2010 and submitted
Hopefully fix the stale site configuration issue. This change attempts to fix the stale site configuration issue. There were a couple things that could potentially go wrong. One is that the cache key used to synchronize the site configurations could potentially go stale, preventing the expiration checks on other SiteConfigurations from returning the correct value. To fix this, we now populate the cache (onlyif it's not already set in the constructor), and check whether the result is None when checking whether it has expired. If it is None, then the key fell out of the cache since the particular thread with that cached SiteConfiguration was last used. Another is that something may be funky with saving timestamps, or with two SiteConfigurations having identical timestamps (due to heavy traffic or something racy). We now increment the value in the cache and compare that. Integers are safer and this shouldn't be racy when using memcached, as incrementing is atomic. However, if people use some other backend mechanism (such as the file backend), this could still be racy if multiple processes are trying to save simultaneously. Unit tests have been added for this. The first synchronization unit test worked before these modifications, but the latter (with the cache key expiring) did not.
Ran the unit tests. They seemed to be fine. Couldn't reproduce this otherwise.