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).
Right...
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...
cheers,
Chris
--
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
