Pool store connections #417
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…tion/session state.
There's some state that they need, notable supports_row_lock_nowait, that wasn't being set anymore in all cases due to pooling the store connection.
…ansaction dangling open.
As for MySQL.
…aise the right error on failure. e.g., https://travis-ci.org/github/zodb/relstorage/jobs/723935887#L1029 Not clear why we would be raising that error in that test though. I con't reproduce locally, even with a slow database.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Much more tightly control their lifetime; they're only needed during TPC (and when getting new OIDs). This should help large installations that have a disparity between reads and writes. Only as many store connections as concurrent TPC commits (plus concurrent new oids) are opened, instead of one for every Connection in the ZODB pool. Worst case, the pool is the same size as the number of Connections, just like before (but there's a tuning knob that might help control that too). Nothing blocks, just as before. But if you need to open a new Connection to handle a read-only request (bursting above the ZODB pool size), instead of requiring two RDBMS connections, now you'll just need one.
Refs #409 (and partly refs #390).
I'm still wrestling with whether there's an approach that can help with load connections; state management there is trickier.
There's a semantic change in
loadBeforeandloadSerial: previously they could, under some circumstances, be used to find states not actually visible to the Storage (transactions committed after the load connection's point of reference). Removing that ability did not break any tests.This is essentially done, I just want to add some more polish and tests, the change note, stuff like that.