Dieter Maurer wrote:
"PostGres" does use looks, lots of them and for different purposes.

Could ZODB use locks to gain a similar performance boost?

The only thing for which "Postgres" does not use locks is reading.
For this is uses MVCC (which we meanwhile adapted for the ZODB
to get rid of "ReadConflictError"s).


And even when locks are used, conflicts arise (they take on the
form of deadlocks). I have seen several of them with Postgres
-- not as deadlocks but as "concurrent update failed".

Ah good, it's not just us then ;-)

Most of our "ConflictError"s come from the session machinery -- because
conflict resolution works there only in a very limited way
(due to limited history availability).

Would having more history help?

Of the rest, 147 of the 177 are either Products.Transience.Transience.Increaser
or Products.Transience.Transience.Length2

Yes, these are our hits -- despite the fact that our "increaser"
is much more intelligent (and increases only rarely and not on each access)

Hmmm, mind if I commit that increaser to the trunk?
There's a ZF board meeting some time soon after which you should get your official invite to become a committer member...



Simplistix - Content Management, Zope & Python Consulting

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -

Reply via email to