Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Refactored how sql exec and prepare errors are handled in murmur #119
Note: Due to the lack of Qt driver agnostic method for detecting disconnections, this is done the hard way.
For additional info see:-
* By default now errors aren't fatal, to try and ensure the best uptime of master servers which could be running many virtual servers. * "disconnect" errors are now detected and the command retried where possible. Note: Due to the lack of Qt driver agnostic method for detecting disconnections, this is done the hard way.
Thanks for the feedback however I would strongly advise this be included in the release as currently the code causes the master server to die if there's a single SQL disconnect, which for a hosting environment is VERY destructive.
If its any help we've been running this patch in production on a machine running over 500 servers without issue for over 2 weeks now.
While it's very, very unfortunate that our release process has stretched this long, it's still too late for us to integrate it this close to release.
We'll integrate it as soon as we've tagged 1.2.4, which is any day now. While it's an inconvenience, people who really need this can, and probably should already be patching this in themselves.
It's not great, I don't really like it, but that's how it is.
Could you perhaps describe how this change deals with transactions? I believe all of our SQL queries in ServerDB.cpp are backed by a TransactionHolder.
If the connection is lost during a transaction, it seems to me that attempting to reconnect to the server (like is proposed in this PR) will break things, unless it's done on a per-transaction basis.
For example, if the client library's connection is lost in the middle of a transaction, all the changes up until that point will presumably be rolled back by the server. If we then try to re-establish the connection, the worst-case scenario is that client will no longer be in a transaction and will presumably just execute the rest of queries (that we intended to be a single transaction) in a non-transactional manner.
That's obviously bad, because we lose data that's rolled back, and we lose the consistency of our database, again because of the rolled back data, but also because the queries we expected to be performed as a single transaction were not.
It's possible I'm missing something, because I'm not very well-versed in QtSql. So I'd like to hear your take on this.