CRM-17464 Deadlocks on acl_cache clearing

    Details

    • Type: Bug
    • Status: Done/Fixed
    • Priority: Minor
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.6.9
    • Fix Version/s: 4.6.14, 4.7.3
    • Component/s: None
    • Documentation Required?:
      None
    • Funding Source:
      Contributed Code

      Description

      We are hitting deadlocks on this query

      CRM_Core_DAO::executeQuery('DELETE FROM civicrm_acl_contact_cache WHERE contact_id IN (SELECT id FROM civicrm_contact WHERE is_deleted = 1)');

      Since it is a delete clause with a subquery it locks the whole table rather than the relevant rows.

      Logically this should be (possibly) done when the contact is trashed rather than at random access times. I say possibly because there is an implicit assumption the acled user cannot see deleted contacts in this action.

      I took a look at the create clause and I feel like it is already aggressively clearing caches from there so adding a specific, non-locking delete clause to the deletecontact function should be enough to warrant removing this query.

        Attachments

          Activity

          [CRM-17464] Deadlocks on acl_cache clearing
          Eileen McNaughton added a comment -

          NB - I did some greps to see if there was any evidence of the BAO create / deleteContact functions being bypassed to delete contacts & did not find any but I would invite others to try too.

          John K. added a comment -

          Any problems with back-porting this for 4.6? I can give it a shot...

          John K. added a comment -

          Eileen, your patch applied cleanly to 4.6 so I've created a PR.

          Eileen McNaughton added a comment -

          I think it should be fine on 4.6 - I probably only did it for 4.7 in the spirit caution

            People

            • Assignee:
              Eileen McNaughton
              Reporter:
              Eileen McNaughton

              Dates

              • Created:
                Updated:
                Resolved: