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.