[ZODB-Dev] ConflictError and POSKeyError with 2.6 CVS :-(

[Toby Dickenson]

On Friday 11 Oct 2002 2:32 pm, Chris Withers wrote:
> Hi,
>
> Having upgraded to 2.6 CVS to try and get rid of BTrees bug I'm now fac=
ed
> with this weird set of events...
>
> This is a long running python ZEO client that stuffs data into a ZODB f=
rom
> a windows machine, here's what turned up in the log of the client:
>

(snip most of the tracebacks; except this one typical example)

> 2002-10-09T19:47:39 ERROR(200)
> Traceback (innermost last):
>    Module Products.ZCatalog.ZCatalog, line 500, in catalog_object
>    Module Products.ZCatalog.Catalog, line 336, in catalogObject
>    Module ZODB.Connection, line 509, in setstate
>    Module ZEO.ClientStorage, line 294, in load
>    Module ZEO.zrpc, line 168, in __call__
> POSKeyError: 000000000006d587


> Any ideas what's going on?


Not precisely, but this is a class of problem that I am particularly=20
interested in. Such problems are of particular interest to me for two=20
reasons:

a. Ive had a few of these too, and I scare easy.

b. With the current state of play of ZODB and storages, the problem is=20
particularly hard to diagnose. (as you might guess from Jeremys untypical=
ly=20
unhelpful response). I am trying to tackle this in DirectoryStorage....


I think there are three broad categories of possible causes to this sympt=
om:

1. Those two objects are present in the database, but can not be loaded f=
or=20
some short-term reason. If this is a FileStorage then you may get some=20
mileage from shutting down the zeo server, deleting the index file, and=20
restarting. Have you done this since the 2.6 upgrade?

2. Those objects really do not exist in the database, therefore we have a=
=20
genuine dangling reference (that is, an object contains a reference to an=
=20
object which does not exist). I see two categories of cause:

    2a. Possibly this was a dangling when the reference was committed. If
    so, this would be a ZODB bug (or your application code. Do you have=20
    and custom conflict resolution code perhaps?). We know that there
    are currently several such bugs, but we believe they only happen in
    extremely rare circumstances. DirectoryStorage now has code to detect
    this during the commit; so far I have not trapped anything interestin=
g.

    2b. Possibly the reference was not dangling when it was committed, bu=
t
    FileStorage has incorrectly removed the object that it was referring
    to (probably during a pack). Historically, FileStorage has had a coup=
le
    of bugs in this area, although none discovered since Zope 2.2 times.
    One of these early FileStorage bugs bit me hard.... This has been
    forgiven now, but it has had a strong influence of DirectoryStorage's
    undoable packing implementation.=20