-
totten authored
---------------------------------------- `CRM_Utils_System::flushCache()` calls `CRM_Utils_Cache::singleton()->flush()`. In `5.3`, this triggered a cascading effect; in development of `5.4.alpha`, some of the cascades were overzealous and we revised to get tighter control over cascading. With an aim to being conservative and reproducing old behavior, I previously patched `5.4.alpha` to add several extra flushes and simulate the old cascades. However, it wasn't really as conservative as hoped -- because the "old behavior" depended on the environment. This patch brings us closer the "old behavior". See also: #284 Before (Behavior in version <=`5.3`) ---------------------------------------- On systems with memory-backed caches, `flushCache()` had an aggressive cascading side-effect where several named caches (`settings`, etc) were also flushed. On systems with a default configuration (SQL+ArrayCache), `flushCache()` had a very limited cascading effect -- it *only cleared the in-process ArrayCache*. The bulk of the cache content was preserved in SQL. Before (Behavior in version ~= `5.4.alpha`) ---------------------------------------- To simulate the cascading effect, `flushCache()` explicitly flushes a half-dozen individual caches. (These half-dozen are chosen to match the old cascade list and exclude some new things which would problematic.) On systems with memory-backed caches, this reproduces the aggressive cascading effect. On systems with a default configuration (SQL+ArrayCache), this amplifies the flushing -- because it also destroys the underlying SQL caches. This has the side-effect of significantly degrading performance of the test suite. After (Behavior with patch) ---------------------------------------- `CRM_Utils_System::flushCache` calls `CRM_Utils_Cache::singleton()->flush()`. To simulate the cascading effect, `flushCache()` explicitly flushes a half-dozen individual caches... *but only on memory-backed* systems. On systems with memory-backed caches, this reproduces the aggressive cascading effect. On systems with a default configuration (SQL+ArrayCache), this is closer to the old behavior. The bulk of the cache remains available in SQL. Based on local spot-checking, this restores performance of the test suite. Comments ---------------------------------------- Deep down, I don't really believe the cascading effect is a good thing. At some point, I'd rather just remove these bits. But in absence of a crystal ball to predict the side-effects of that, I think it's good to find a better approximation of the old behavior.
70423e0d