I think I've figured out what goes wrong. The exception occurs during
automated testing, with a temporary root for the database storage among
other things. This root is deleted once
finishes, and before the database is closed it seems. The resulting
exception is a bit confusing however, maybe ZODB should be a bit more
robust toward this sort of scenario?
Maybe a corresponding exception could be raised if the storage doesn't
exist on disk,
On 2/15/07, Arve Knudsen <[EMAIL PROTECTED]> wrote:
On 2/14/07, Dieter Maurer <[EMAIL PROTECTED]> wrote:
> Arve Knudsen wrote at 2007-2-14 16:34 +0100:
> >I sometimes receive an exception when closing a ZODB, due to it trying
> >remove a lock file which doesn't exist. Given the backtrace can you
> tell me
> >whether this is something which should be rectified in ZODB? I suspect
> >problem lies in the fact that the database is closed from atexit, maybe
> >has already registered some kind of cleanup from atexit?
> Have you registered a "close" function for your storage, too?
> The API is a bit inconsitent:
> While you open both a storage and a DB, the "DB.close()" implicitly
> closes the storage as well.
> Thus, if you have registered a "storage.close", the " DB.close()"
> might find the storage already closed and get an error as you
I haven't scheduled the storage for closing, it only exists within my database.
I added some debugging statements to see if the ZODB storage were closed
several times, but it was not so. So it seems this is internal to ZODB.
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org