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 loadBefore and loadSerial: 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.
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.