[ZODB-Dev] BTree set question

Christian Robottom Reis kiko at async.com.br
Fri Feb 27 07:09:46 EST 2004


On Fri, Feb 27, 2004 at 12:34:31AM -0500, Tim Peters wrote:
> > I'm also happy to work around the current set of issues (now that I
> > know them!) because I think it likely helps Zope performance in highly
> > concurrent situations.
> 
> Have you tried ZODB 3.3a2 yet?  While write conflicts can kill performance
> under high load, I wonder whether read conflicts don't actually cause more
> pain in the world:  lots of people seem to try to ignore them (whether by
> design or accident I'm not sure), and get into real semantic trouble as a

They cause a world of pain to me, at least. In my case, there's no such
thing as a "retryable transaction" since I don't have a request in my
hand to repeat. Some of my transactions are long, going through three
and four-step wizards. And when the user reaches the end, clicking
"Finish" and having it bomb out on him because there's been a change
somewhere in the indexes is hardly fun.

I'm happy to live with write conflicts because they indicate something
bad actually did happen, of course. And the semantics you described
aren't bad (though a bit on the conservative side for my use case).

> result.  MVCC is a pretty aggressive approach toward that class of problem
> (you avoid read conflicts at the cost of seeing more "stale" data -- but,
> again, for most apps, and Zope in particular, stale data isn't really a
> problem, just so long as it's consistent with how the world really was at
> *some* time in the recent past; but *some* apps can't tolerate that).

Ours luckily can. Unfortunately, this change also involves changing
IndexedCatalog to compile with ZODB-3.3, and this involves sifting
through the ExtensionClass changes which I haven't done yet. So I've
added a queuing feature to IndexedCatalog which skirts the problem
somewhat, for now -- it would have been useful anyway.

Take care,
--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331



More information about the ZODB-Dev mailing list