Details
-
New Feature
-
Status: Stalled (View Workflow)
-
Minor
-
Resolution: Unresolved
Description
Please, provide a way to enable the "rollback XA transaction behavior at disconnect" that we had before the fix for MDEV-742 (in versions < 10.5.2), at least at session level with a variable like:
set session rollback_xa_at_disconnect=true;
|
This may be useful for those who upgrade from 10.4 or older versions to 10.5+ and have application that expects the previous behaviour. Such applications end up with XA transactions hanging in prepared state now, when sessions got disconnected for whatever reason, and eventually block something (and this is when they are usually noticed).
Attachments
Issue Links
- relates to
-
MDEV-742 LP:803649 - Xa recovery failed on client disconnection
-
- Closed
-
Activity
My two cents is that knielsen's patch makes sense. One way or another, we are breaking consistency and durability guarantees, and Kristian's patch makes both the use case and the limitations obvious, both in its name and description. Some sort of ignore-* based option, where more general, may appear more like a new feature and confuse users. I also think the new option should debut as deprecated, as I imagine at some point in the future, once 10.4 has been EoL for long enough, we can remove the option altogether. So we make it extra obvious that it is not a long-term solution, and the application should eventually be updated.
Well, I can't comment on what is more confusing. I'd say any chosen one would do to an extent.
However I think the fact (should've been mentioned) that ignore-xa-commands and xa-commit-in-one-phase preserves the 10.3 binlogging of XA speaks in favor or that direction.
More information about the use case we're fixing. The user has a message queue and a MariaDB both participating in a distributed transaction with JBoss as a TC. After upgrading MariaDB some queries got slower and it seems that application-side timeout started killing the connection to MariaDB, sometimes after prepare. The user thought that reverting to pre-10.5 behavior, where the disconnect would automatically commit a prepared transaction would solve the issue.
But the old behavior was not to commit, it was to rollback. Rolling back a prepared transaction means messages will get lost (deleted from the message queue, not inserted into MariaDB). The correct fix here is likely to fix the slowdown caused by the upgrade.
So, basically, there is no user request and no use case to implement it right now. Let's wait for one.
Hopefully, somebody hitting this issue will add a comment below with more background info
Reverted for now, until there's a consensus of how to fix it.