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 testing 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, e.g. "StorageMissing"?
Arve On 2/15/07, Arve Knudsen <[EMAIL PROTECTED]> wrote:
Hi, Dieter 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 > to > >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 > the > >problem lies in the fact that the database is closed from atexit, maybe > ZODB > >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 > reported. 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. Arve
_______________________________________________ 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
