Description:
http://mysqlserverteam.com/mysql-5-7-12-part-2-improving-the-mysql-protocol/ talks about the advantages of the new X protocol. One of these is the advantage of pipelining.
For low latency connections this is less important but for higher latency connections this can be important.
One thing a lot of ORMs do when connecting to MySQL is to request information about the server's state. This may include information such as:
* max_allowed_packet (the Go driver always does this)
* version (MySQL version, as different versions may not behave the same)
* autocommit - this setting is often set, but it's good to know when the server setting is.
Other variables may also be needed/useful etc.
So the current connection behaviour is synchronous between the "authentication phase" and the "sending commands" phase iff the ORM needs to be aware of the MySQL version. While that may not be an issue now. We already know that 8.0 will have new features. It may be therefore that 8.0 behaves differently and thus the ORM will want to change it's behaviour depending on the version of the server it's talking to.
How to repeat:
See above
Suggested fix:
My idea here is to add an extra field with the AuthenticationStart or AuthenticateContinue message (depending on the type of authentication used:
RequestedServerVariables which would be a "list" of variables which we'd like to get back IFF the authorisation succeeds and we have access to those variables.
If authorisation succeeds then the AuthenticateOk packet could return with the values of these requested, or indicate that they are not available.
Current behaviour would not change, and an application that is using the X protocol but which does not understand this would not notice.
However, an application which does recognise this special return value would not have to request them again and wait for their response, and thus could immediately start to send further queries taking into account this known information.
To summarise: this is just an idea. However, I've seen latency issues when an application talks to a database server in a different datacentre, and this has lead to the need to adapt code. Pipelining can help reduce some of that friction and this would be a way to further help the user if the drivers use this potential extra feature when using the X protocol.
© 2024, Oracle Corporation and/or its affiliates