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.
This commit is contained in:
@ -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
|
For more information about this configuration entry, please see
|
||||||
[Global Settings](../Getting-Started/Configuration-Guide.md#global-settings).
|
[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
|
### User data cache
|
||||||
|
|
||||||
The user data cache stores the cached credentials that are used by some router
|
The user data cache stores the cached credentials that are used by some router
|
||||||
|
@ -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
|
by the back end server. Connections will be selected that match the user name and
|
||||||
protocol for the new request.
|
protocol for the new request.
|
||||||
|
|
||||||
**Please note** that because persistent connections have previously been in use, they
|
Starting with the 2.1 version of MaxScale, when a MySQL protocol connection is
|
||||||
may give a different environment from a fresh connection. For example, if the
|
taken from the pool the backend protocol module resets the session state. This
|
||||||
previous use of the connection issued "use mydatabase" then this setting will be
|
allows persistent connections to be used with no functional limitations.
|
||||||
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
|
The session state is reset when the first outgoing network transmission is
|
||||||
will issue fresh requests such as "use" to establish the desired configuration. In
|
done. This _lazy initialization_ of the persistent connections allows
|
||||||
exceptional cases this feature could be a problem.
|
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
|
It is possible to have pools for as many servers as you wish, with configuration
|
||||||
values in each server section.
|
values in each server section.
|
||||||
|
Reference in New Issue
Block a user