X Don't keep ZBigFile activated during whole current transaction
If we keep it activated, there could be a problem at Resync time - if Resync sees that old zhead.At is outside of DB.δtail coverage it will invalidate all zhead.cache objects, not only changed objects. That means that even non-changed and being kept active ZBigFile will be invalidated and oops - PInvalidate will panic. We could avoid it via deactivating all ZBigFiles on each transaction update, but that can be too expensive if there are many ZBigFiles. We could avoid the problem another way - add to ZODB/go API to request that DB.δtail covers particular connection. That in turn would mean we have to also extend ZODB/go API to release connection from affecting DB via such constraint. Even if first step could be done via e.g. another flag, the second step - release - is not very clear - we already have connection "release" on transaction completion and adding e.g. conn.Close() in addition to that would be ambiguous for users. Also, if wcfs is slow to process invalidations for some reason, such constraint would mean DB.δtail would ↑ indefinitely. -> we can solve the problem in another way: don't keep ZBigFile always activated and just do activation/deactivation as if working with ZODB objects regularly. This does not add any complications to code flow and from the performance point of view we can practically avoid the slowdown by teaching zodbCacheControl to also pin ZBigFile in live cache.
Showing