Re: How cache invalidations work (and hack to listen in) (was Re: Applause for ZODB! And a question: How do you get pending change info from a transaction object?)

> On May 6, 2018, at 11:43, Jim Fulton <[email protected]> wrote:
> 
>> Because a ZODB connection (roughly)
>> 
> Roughly?
>  
>> exposes a consistent view (version) of the database as-of the point in time at which it was opened,

"Roughly" because it's not really guaranteed to be the *whole* database at the time at which it was opened. Just like REPEATABLE READ, it's guaranteed for the individual rows/objects as-of the time they are first touched. I don't think ZODB guarantees what SQL would describe as SNAPSHOT isolation.

Maybe FileStorage and ZEO do guarantee the *whole* database now in ZODB 5 since it uses storage.loadBefore() (I don't think they used to make that guarantee), but RelStorage opens its SQL connections in REPEATABLE READ isolation level (except on Oracle, which has a different notion for what isolation levels mean). 

Hmm, as I'm looking, I see that's true for MySQL; PostgreSQL uses SERIALIZABLE, which doesn't mean the same thing in 9.1+ as it did when RelStorage was written---prior to 9.1 it meant REPEATABLE READ but now it "really" means SERIALIZABLE, so RelStorage could potentially be faster on 9.1+ databases by going back to REPEATABLE READ. Any objections to dropping 9.0? It went EOL in 2015 :) 

Jason

-- 
You received this message because you are subscribed to the Google Groups "zodb" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.