fix: commit transaction after topology query (fixes #1168)

[finalchild]

Summary

This PR tries to fix #1168, where queryForTopology automatically fired by FailOverPlugin opens a transaction and never closes, resulting in an unexpected change in the connection state.

Description

If the connection doesn't auto-commit and wasn't in a transaction already, queryForTopology leaves a new transaction open. We have to either commit or roll back the transaction.

Note that this PR is a suggestion merely based on a speculation. I haven't tested that this works, nor do I fully understand the meaning of this.hostListProviderService.isInTransaction(). Please review and close/edit as you see fit.

Additional Reviewers

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[aaron-congo]

Hi @finalchild, I believe the fix for this has been merged already (see here). Are you okay with me closing this PR?

[finalchild]

@aaron-congo Hi. I haven't got much time to investigate this issue deeper, but I'm not completely convinced that the released fix prevents the whole class of issue from occurring.

What if one calls PreparedStatement.getParameterMetaData while not in a transaction and auto-commit is false? The wrapper would try to update the topology, executing a query, and leave a transaction open. Later, when some state-sensitive method like setReadOnly is called, an error will occur because a transaction is open, while the dev would expect that no transaction should be open.

I believe the only complete solution is either closing the transaction later (like my patch), or temporarily turning on auto-commit in the first place.

I found this article which explains the behavior of auto-commit, which looks pretty harmless to save and recover later if there is no concurrency issues.
https://weinan.io/2017/05/21/jdbc-part5.html