[MDEV-28821] Better support for Session tracking Created: 2022-06-13  Updated: 2022-06-14

Status: Open
Project: MariaDB Server
Component/s: None
Fix Version/s: None

Type: Task Priority: Major
Reporter: Diego Dupin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Some connectors (c/c/r2dbc…) only implements CLIENT_SESSION_TRACKING, but not CLIENT_DEPRECATE_EOF.

There is different reasons for that : in result-set, The intermediate EOF_Packet contains interesting pieces of information in status_flags like SERVER_MORE_RESULTS_EXIST, SERVER_PS_OUT_PARAMS

MySQL doesn't consider this as a problem, but that has consequences : R2DBC for example is an asynchronous driver, streaming data, that need to identify resultset type (standard / 'output parameter' resultset) BEFORE reading resultset rows.

CLIENT_DEPRECATE_EOF capability cannot be set. Resultset then ends with an EOF_Packet, without session tracking information.

Now that we want having session tracking information at any time (example MXS-4153) it would be better to have a new capability CLIENT_SEMI_DEPRECATE_EOF that behave like CLIENT_DEPRECATE_EOF without removing resultset intermediate EOF.

 Comments   
Comment by markus makela [ 2022-06-14 ]

Would the connectors that do not support DEPRECATE_EOF protocol be able to use this new SEMI_DEPRECATE_EOF protocol without modifications? If so, would the only difference be the size of the EOF packet and the way it should be interpreted?

Comment by Diego Dupin [ 2022-06-14 ]

markus makela connectors needs modification to support this SEMI_DEPRECATE_EOF :
COM_STMT_PREPARE response would still not have the intermediate/ending EOF packet like for CLIENT_DEPRECATE_EOF. (That part is questionnable, we can keep EOF )

For resultset, compare to client without CLIENT_DEPRECATE_EOF capability, the only difference will be the last packet beeing an OK_Packet with 0xfe header.
For Maxscale point of view, resultset packet identification will be something like that after intermediate EOF_Packet:

  • 0xff => ERROR
  • 0xfe => might be a very long TEXT row data, an EOF_Packet or an OK_Packet with a 0xfe header.
    • no DEPRECATE_EOF and no SEMI_DEPRECATE_EOF and packet length < 8 => EOF_Packet
    • DEPRECATE_EOF / SEMI_DEPRECATE_EOF enable and packet length < 0xffffff => this is an OK_packet
    • else this is a row.
  • other => row
Generated at Thu Feb 08 10:03:44 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.