[MXS-2655] Transaction replay fails when session commands modify the server state inside it Created: 2019-09-03 Updated: 2019-10-10 Resolved: 2019-10-07 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | readwritesplit |
| Affects Version/s: | 2.4 |
| Fix Version/s: | 2.5.0 |
| Type: | Bug | Priority: | Major |
| Reporter: | markus makela | Assignee: | markus makela |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Sprint: | MXS-SPRINT-90, MXS-SPRINT-91 | ||||||||
| Description |
|
The following SQL will fail to replay even though the results are similar:
This is caused by the fact that the state of the session is changed by the set autocommit=0 statement which alters the status bytes the response to the BEGIN returns. The correct way to do this would be to execute any session commands inside the transaction in the same order the appeared in. |
| Comments |
| Comment by markus makela [ 2019-09-06 ] |
|
To correctly handle this, the session commands done inside a transaction should be only executed on the server where the transaction is being executed. Once the transaction is finished (committed or rolled back) the session commands must be executed on the servers that did not participate in the transaction. |
| Comment by markus makela [ 2019-09-16 ] |
|
In my opinion this can't be done on 2.4 without making the session command code even more convoluted than it already is. Some refactoring and simplification of the whole session command subsystem would greatly contribute to making this a less daunting task. |
| Comment by markus makela [ 2019-10-07 ] |
|
The session command execution is now "transactional" in 2.5: commands that modify the session state are only executed on the server where the transaction is open and are propagated to other servers only once the transaction is complete. |