hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MXS-1474 Update the cache documentation

Browse Source 
Introduce the configuration parameter `cache_inside_transactions`.
This commit is contained in:
Johan Wikman
2017-10-23 12:40:12 +03:00
parent 7a94999425
commit e6af3c3f26
1 changed files with 29 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
Documentation/Filters/Cache.md
View File

@ -10,7 +10,7 @@ The cache filter is a simple cache that is capable of caching the result of
SELECTs, so that subsequent identical SELECTs are served directly by MaxScale, SELECTs, so that subsequent identical SELECTs are served directly by MaxScale,
without the queries being routed to any server. without the queries being routed to any server.
The cache will be used and populated in the following circumstances: By _default_ the cache will be used and populated in the following circumstances:
* There is _no_ explicit transaction active, that is, _autocommit_ is used, * There is _no_ explicit transaction active, that is, _autocommit_ is used,
* there is an _explicitly_ read-only transaction (that is,`START TRANSACTION * there is an _explicitly_ read-only transaction (that is,`START TRANSACTION
READ ONLY`) active, or READ ONLY`) active, or
@ -22,6 +22,9 @@ been started with `BEGIN`, `START TRANSACTION` or `START TRANSACTION READ
WRITE`, then the cache will be used and populated until the first `UPDATE`, WRITE`, then the cache will be used and populated until the first `UPDATE`,
`INSERT` or `DELETE` statement is encountered. `INSERT` or `DELETE` statement is encountered.
The default behaviour can be altered using the configuration parameter
[cache_inside_transactions](#cache_inside_transactions).
By default, it is *ensured* that the cache is **not** used in the following By default, it is *ensured* that the cache is **not** used in the following
circumstances: circumstances:
@ -251,6 +254,31 @@ If `assume_cacheable` is specified, then all `SELECT` statements are
assumed to be cacheable and will be parsed *only* if some specific rule assumed to be cacheable and will be parsed *only* if some specific rule
requires that. requires that.
#### `cache_inside_transactions`
An enumeration option specifying how the cache should behave when there
are active transactions:
* `never`: When there is an active transaction, no data will be returned
from the cache, but all requests will always be sent to the backend.
The cache will be populated if the transaction is explicitly read only
or if no non-SELECT statement has been encounted.
* `read_only_transactions`: The cache will be used and populated inside
_explicitly_ read-only transactions. If the transaction is not explicitly
read only, the cache will be populated (but not used) until the first
non-SELECT statement.
* `all_transactions`: The cache will be used and populated inside
explicitly read-only transactions. Inside transactions that are not
explicitly read-only, the cache will be used and populated _until_ the
first non-SELECT statement.
```
cache_inside_transactions=never
```
Default is `all_transactions`.
The values `read_only_transactions` and `all_transactions` have roughly the
same effect as changing the isolation level of the backend to `read_committed`.
#### `debug` #### `debug`
An integer value, using which the level of debug logging made by the cache An integer value, using which the level of debug logging made by the cache