[ZODB-Dev] Re: [Zope-dev] Conflict reduced BTrees for catalogin

[Tim Peters]

[Dieter Maurer]
> I know already one problem:
>
>   Letting "_p_independent" return 1 allows to see state modified
>   after the current transaction started.
>
>   When I do this for catalog data but not other data,
>   then searches can return objects that are not yet accessible.
>
> I have abandoned the "_p_independent for BTrees" route

Giving up on that sounds like a good idea.  On Friday, Jeremy & I worked out
examples where ignoring read conflicts in BTrees can cause a transaction to
see plain wrong results too.  BTrees have 3 different kinds of internal
cross-object pointers, which are not independent, but store what's supposed
to be redundant information.  Depending on the operation at hand, one kind
of pointer is used because it's more efficient than the other kinds for that
purpose.  If one flavor of pointer gets out of synch with the others,
different operations can return pairwise inconsistent results.  For example,

    abtree.has_key(akey)
and
    akey in list(abree.keys())

use different kinds of pointers, and if they get inconsistent then one
expression can return true at the same time the other returns false.  That's
a real mess.

> and will go for "ReadCommitted" isolation level.
> This provides for much clearer semantics.

I hope so <wink>.