ZODB isolation level (was Re: How cache invalidations work)
Jim Fulton <[email protected]> Sun, 6 May 2018 12:01:00 -0600
| Newsgroups | gmane.comp.web.zope.zodb |
|---|---|
| Message-ID | <CAPDm-FgbnNKyMuThMW1fy0bWaCKAj+nPmOk9WvbKLRf9e-RMAQ@mail.gmail.com> |
On Sun, May 6, 2018 at 11:08 AM, Jason Madden <[email protected]> wrote: > > > > 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. Yes it is. > Just like REPEATABLE READ, it's guaranteed for the individual rows/objects > as-of the time they are first touched. Nope. > I don't think ZODB guarantees what SQL would describe as SNAPSHOT > isolation. > ZODB promises snapshot isolation, modulo conflict resolution, which weakens consistency, and the ability to optionally check that objects read weren't modified, which strengthens it. > 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), They have guaranteed this at least since MVCC was officially introduced in ZODB 3. ZODB 5 simply made the logic for this less tortured. but RelStorage opens its SQL connections in REPEATABLE READ isolation level > (except on Oracle, which has a different notion for what isolation levels > mean). > From the Postgres 9.1 docs: https://www.postgresql.org/docs/9.1/static/transaction-iso.html "The *Repeatable Read* isolation level only sees data committed before the transaction began" That's snapshot isolation. (Note that snapshot isolation is slightly weaker that full serializability.) I realize that that is just Postgres, and they say that their version of this provides stronger guarantees. > 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 :) > Works for me. I'd be interested to know what difference it makes. Jim -- Jim Fulton http://jimfulton.info -- 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.