From d69025bfa691e96ddfdac40b9f581f7c784117f1 Mon Sep 17 00:00:00 2001 From: Markus Makela Date: Tue, 1 Nov 2016 11:20:34 +0200 Subject: [PATCH] Add changes to persistent connections to documentation The documentation now states that, starting with 2.1, the persistent connections will reset the MySQL session state when they are taken into use. --- .../MaxScale-2.1.0-Release-Notes.md | 12 ++++++++++ .../Tutorials/Administration-Tutorial.md | 23 +++++++++++++------ 2 files changed, 28 insertions(+), 7 deletions(-) diff --git a/Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md b/Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md index 7ffdace44..d5617474f 100644 --- a/Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md +++ b/Documentation/Release-Notes/MaxScale-2.1.0-Release-Notes.md @@ -57,6 +57,18 @@ by default, is configured using the new global configuration entry `log_throttli For more information about this configuration entry, please see [Global Settings](../Getting-Started/Configuration-Guide.md#global-settings). +### Persistent Connections + +Starting with the 2.1 version of MariaDB MaxScale, when a MySQL protocol +persistent connection is taken from the persistent connection pool, the +state of the MySQL session will be reset when the the connection is used +for the first time. This allows persistent connections to be used with no +functional limitations and makes them behave like normal MySQL +connections. + +For more information about persistent connections, please read the +[Administration Tutorial](../Tutorials/Administration-Tutorial.md). + ### User data cache The user data cache stores the cached credentials that are used by some router diff --git a/Documentation/Tutorials/Administration-Tutorial.md b/Documentation/Tutorials/Administration-Tutorial.md index e9f4e5929..14d64b807 100644 --- a/Documentation/Tutorials/Administration-Tutorial.md +++ b/Documentation/Tutorials/Administration-Tutorial.md @@ -106,13 +106,22 @@ than `persistmaxtime` seconds. It was also be discarded if it has been disconne by the back end server. Connections will be selected that match the user name and protocol for the new request. -**Please note** that because persistent connections have previously been in use, they -may give a different environment from a fresh connection. For example, if the -previous use of the connection issued "use mydatabase" then this setting will be -carried over into the reuse of the same connection. For many applications this will -not be noticeable, since each request will assume that nothing has been set and -will issue fresh requests such as "use" to establish the desired configuration. In -exceptional cases this feature could be a problem. +Starting with the 2.1 version of MaxScale, when a MySQL protocol connection is +taken from the pool the backend protocol module resets the session state. This +allows persistent connections to be used with no functional limitations. + +The session state is reset when the first outgoing network transmission is +done. This _lazy initialization_ of the persistent connections allows +MaxScale to take multiple new connections into use but only initialize the +ones that it actually needs. + +**Please note** that in versions before 2.1 the persistent connections may give +a different environment when compared to a fresh connection. For example, if the +previous use of the connection issued a "USE mydatabase;" statement then this +setting will be carried over into the reuse of the same connection. For many +applications this will not be noticeable, since each request will assume that +nothing has been set and will issue fresh requests such as "USE" to establish +the desired configuration. In exceptional cases this feature could be a problem. It is possible to have pools for as many servers as you wish, with configuration values in each server section.