Thanks for the fast reply Casey. Casey Duncan wrote: > On Thursday 27 September 2001 12:48 pm, Oliver Bleutgen allegedly wrote: >> Hi, >> I'm resending this to zope-dev because on zope >> nobody answered, it would be very nice if someone >> could step up with a small hint. >> >> >> >> Can somenone briefly explain what exactly gets >> locked in zope 2.3.3's catalog when it tries to >> index an object which is hold in a version? >> The whole catalog?
> Any Btree buckets (in the indexes) which get changed get locked, which can > effectively lock out other changes to the catalog. This is a limitation of > the way the indexes are implemented, for which, sadly, there is no easy > fix. >> >> I found some answers which indicate that it has >> to do with the catalog when we see version lock errors >> where there shouldn't be any (from a naive POV). >> I would like to know how far reaching these problems >> are, because I'm currently rewriting an application, >> and I might be able to work around that. > I would suggest that if any objects are reindexed in a version, that no > cataloged objects should be reindexed in any other version until that > version > is saved. I hope I understand you correctly, but I'd say that if there's already a locked bucket, I've lost. There's no guarantee how long this particular version will stay uncommitted. I would also have to check anyhow whether there is a lock somewhere in the catalog's index. > You could also get around that by deferring the indexing until the version > is > commited, but this will take some coding on your part. This seems easier - if I'm a little bit lax about when the indexing occurs. Like making the object only index/reindex/unindex itself if it's not in a version, and combining that with a nightly cronjob which reindexes all (non-versioned) documents. With "some coding on your part" you mean making Version.py more intelligent? Like instead of just doing commitVersion(s,'') doing the following: 1) search for objects which have been deleted in the version 2) search for objects which want to catalog themselves and are locked in version s 3) unindex the objects found in 1) 4) commit version 5) index/reindex objects found in 2) Where it's not clear to me how to prevent that 3) and 5) will not itself get versioned. > Ultimately I think > that ZCatalog should do this for you, or at least somehow let indexes have > concurrent versioning (any volunteers?) I should say that I really don't grasp this ZODB voodoo, but I suspect that this will also be not too easy. AFAIK, the decision to write "in" a version (and in which) is taken deep down in zope's innards. > I am thinking about writing a fishbowl proposal for ZCatalog upgrades > sometime next month, and this is one potential problem areas to address > there, especially as things like the CMF make it more ubiquitous If I don't misunderstand how versions work (not unlikely), it might be necessary in the end rather to improve versions than the zcatalog in order to remedy this specific problem. thanks again, oliver _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )