Hi, Dieter<br><br><div><span class="gmail_quote">On 2/14/07, <b class="gmail_sendername">Dieter Maurer</b> <<a href="mailto:dieter@handshake.de">dieter@handshake.de</a>> wrote:</span><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Arve Knudsen wrote at 2007-2-14 16:34 +0100:<br>>I sometimes receive an exception when closing a ZODB, due to it trying to<br>>remove a lock file which doesn't exist. Given the backtrace can you tell me<br>>whether this is something which should be rectified in ZODB? I suspect the
<br>>problem lies in the fact that the database is closed from atexit, maybe ZODB<br>>has already registered some kind of cleanup from atexit?<br><br>Have you registered a "close" function for your storage, too?
<br><br>The API is a bit inconsitent:<br><br> While you open both a storage and a DB, the "DB.close()" implicitly<br> closes the storage as well.<br><br> Thus, if you have registered a "storage.close", the "
DB.close()"<br> might find the storage already closed and get an error as you<br> reported.</blockquote><div><br>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.
<br><br>Arve </div><br></div><br>