Uploaded image for project: 'MariaDB MaxScale'
  1. MariaDB MaxScale
  2. MXS-4419

Transaction state is not tracked correctly for pipelined queries

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 22.08.2
    • 23.08.0
    • Core
    • None
    • MXS-SPRINT-184

    Description

      Executing the following queries in a pipelined manned without waiting for the results will work as expected but internally cause the transaction tracking to not work correctly.

      BEGIN;
      SELECT @@server_id;
      COMMIT;
      

      The logs from MaxScale show the problem:

      2022-11-30 22:06:09   info   : (1) (RW-Split-Router); > Autocommit: [enabled], trx is [open], cmd: (0x03) COM_QUERY, plen: 10, type: QUERY_TYPE_BEGIN_TRX, stmt: BEGIN 
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Route query to master: server1 <
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Transaction starting on 'server1'
      2022-11-30 22:06:09   info   : (1) (server1); Storing COM_QUERY while in state 'Authenticating': BEGIN
      2022-11-30 22:06:09   info   : (1) (RW-Split-Router); > Autocommit: [enabled], trx is [open], cmd: (0x03) COM_QUERY, plen: 23, type: QUERY_TYPE_READ|QUERY_TYPE_SYSVAR_READ, stmt: SELECT @@server_id 
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Route query to master: server1 <
      2022-11-30 22:06:09   info   : (1) (server1); Storing COM_QUERY while in state 'Authenticating': SELECT @@server_id
      2022-11-30 22:06:09   info   : (1) (RW-Split-Router); > Autocommit: [enabled], trx is [open], cmd: (0x03) COM_QUERY, plen: 11, type: QUERY_TYPE_COMMIT, stmt: COMMIT 
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Route query to master: server1 <
      2022-11-30 22:06:09   info   : (1) (server1); Storing COM_QUERY while in state 'Authenticating': COMMIT
      2022-11-30 22:06:09   info   : (1) Authentication to 'server1' succeeded.
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Reply complete from 'server1' (OK: 0 warnings)
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Transaction complete on 'server1'
      2022-11-30 22:06:09   info   : (1) Authentication to 'server2' succeeded.
      2022-11-30 22:06:09   info   : (1) Authentication to 'server3' succeeded.
      2022-11-30 22:06:09   info   : (1) Authentication to 'server4' succeeded.
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Reply complete from 'server1' (Resultset: 1 rows in 70B)
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Transaction complete on '<no target>'
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Reply complete from 'server1' (OK: 0 warnings)
      2022-11-30 22:06:09   info   : (1) [readwritesplit] (RW-Split-Router); Transaction complete on '<no target>'
      

      This happens because the transaction state is tracked on the client protocol level which doesn't wait for the response packets before advancing into the next transaction state. This needs to be changed so that the transaction state advances to the next state only when the response to it is received. Ultimately, the tracking must also be done on the component level in the routing chain as separate branches in it are logically at a different transaction state. This, however, is not as important as the routers mostly handle this problem.

      Attachments

        Activity

          People

            markus makela markus makela
            markus makela markus makela
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

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