Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-19995

Spider XA operations may lock spider_xa_member for a long time, limiting concurrency

    XMLWordPrintable

Details

    Description

      Some spider XA operations, most critically XA PREPARE, through either explicit or internal XA, keep the mysql.spider_xa_member locked while executing commands on backends.
      During that time, no other spider XA transaction is able to XA PREPARE or XA COMMIT, as they are waiting for the table lock.

      Considering the case of XA PREPARE (through spider_internal_xa_prepare):
      It keeps the table locked while executing XA END followed by XA PREPARE, on each involved backend, sequentially.
      That can be particularly bad if, for example:

      1. the latency between spider and backends is non-negligible
      2. multiple backends are involved
      3. the backend thread or connection somehow gets killed/stuck, and spider_net_read_timeout is set too high (default seems to be 600 seconds).

      This behavior limits throughput by latency and in the worst case (#3) may block other transactions for a long time.

      Other functions which seem to do something similar are spider_internal_xa_commit_by_xid and spider_internal_xa_rollback_by_xid.

      Attachments

        Activity

          People

            ycp Yuchen Pei
            lpacheco Leandro Pacheco (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.