'name'
);
- CRM_Contact_BAO_Contact_Utils::clearContactCaches();
+ //if (!$config->doNotResetCache) {
+ // Note: doNotResetCache flag is currently set by import contact process and merging,
+ // since resetting and
+ // rebuilding cache could be expensive (for many contacts). We might come out with better
+ // approach in future.
+ // HACK: Dave did this due to many donations and other requests failing due to acl_cache table locks (similar to what Dave disabled)
+ //CRM_Contact_BAO_Contact_Utils::clearContactCaches();
+ //}
if ($invokeHooks) {
if ($isEdit) {
}
}
- CRM_Contact_BAO_Contact_Utils::clearContactCaches();
+ // also reset the acl cache
+ $config = CRM_Core_Config::singleton();
+ if (!$config->doNotResetCache) {
+ // HACK: Dave commented this out on 12/09/2014 due to lock wait timeouts on the acl cache that caused donations to fail.
+ //CRM_ACL_BAO_Cache::resetCache();
+ }
+
+ // reset the group contact cache for all group(s)
+ // if this group is being used as a smart group
+ // @todo consider what to do here - it feels like we should either
+ // 1) just invalidate the specific group's cache(& perhaps any parents) & let cron do it's thing or
+ // possibly clear this specific groups cache, or just call opportunisticCacheFlush() - which would have the
+ // same effect as the remove call. The reservation about that is that it is no more aggressive for the group that
+ // we know is altered than for all the others, or perhaps, more the point with it's parents & groups that use it in
+ // their criteria.
+ // HACK: Dave had to disable this, too! (similar to what Dave disabled)
+ //CRM_Contact_BAO_Contact_Utils::clearContactCaches();
CRM_Utils_Hook::post($op, 'GroupContact', $groupId, $contactIds);