[ZODB-Dev] OOBucket ReadConflictErrors

[Christian Robottom Reis]

Okay, so I'm stumped on this one. I'm running into ReadConflictErrors
for OOBuckets attached to my Catalog class, and I sincerely don't know
why. Using the script below:

    from BTrees.OOBTree import OOBucket

    def prep(c,r):
        if not r.has_key('x'):
            r['x'] = OOBucket()
        else:
            print r['x'].keys()

    def go(c, r, n):
        # c is a connection
        # r the database root
        # n should be a unique value
        while 1:
            b = r['x']
            b[(n, 1)] = (1, n)
            c.getTransaction().commit()
            del b[(n, 1)]
            c.getTransaction().commit()
            print "loop"

Spinning two separate clients on an empty repository served up by ZEO,
calling first prep() on one, committing, c.sync() and prep() on the
other, and commiting, I start them both calling g(c,r,n). Here's what I
get in one of the clients, normally after a couple of "loop"s:

    Traceback (most recent call last):
      File "<console>", line 1, in ?
      File "./y.py", line 17, in go
        del b[(n, 1)]
      File "/mondo/local//lib/python2.3/site-packages/ZODB/Connection.py",
    line 568, in setstate
        invalid = self._is_invalidated(obj)
      File "/mondo/local//lib/python2.3/site-packages/ZODB/Connection.py",
    line 597, in _is_invalidated
        raise ReadConflictError(object=obj)
    ReadConflictError: database read conflict error (oid 0000000000292b79,
    class IndexedCatalog.BTrees.OOBTree.OOBucket)

Now I can't figure out *why* I'm conflicting on deletion. I figure
there's some sort of race condition here, because it only seems to
happen if I modify the bucket *while* the other client is doing the
commit() -- are commit()s race-safe?

I was assuming I would never ReadConflict on b given that I've already
loaded the bucket's state into the cache (via prep() first then whenever
I'm looping through the while loop), but it seems I'm wrong. This is odd
because it seems to contradict what Shane and Jeremy have told me in the
past.

This throws a wrench in my "reduce-index-conflicts-via-queued-updated"
strategy! Hoping somebody can offer a hand here,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331