Tim Peters wrote:

If a client restarted during the day, wouldn't you find evidence of that in
your logs?


This is all there is to it, where Data.fs has a single large OOBTree
attached as to the root under key "tree":

st = ZODB.FileStorage.FileStorage('Data.fs')
db = ZODB.DB(st)
cn = db.open()
rt = cn.root()
tree = rt['tree']

<extension class BTrees.OOBTree.OOBTree at 00C99660>

cn.close()  # DON'T BLINK

Yep, I understand the mechanics, just not where it's happening ;-)

BTW, because we didn't see ConnectionStateError at the time cn.close() was
done, we know that no objects loaded from the Connection were left in a
modified state.

That sounds like a good thing :-)

BTW, I haven't seen a traceback associated with your "shouldn't load state"
problems.  Do any exist?  (I understand they may not be logged, I'm
wondering if you can see them from the ZMI.  If it _is_ unintentional
caching, a traceback could be invaluable.)

I agree.

Do you mind if I apply the following patch to the ZODB trunk?

Index: Connection.py
--- Connection.py       (revision 39510)
+++ Connection.py       (working copy)
@@ -725,7 +725,7 @@
         if self._opened is None:
             msg = ("Shouldn't load state for %s "
                    "when the connection is closed" % oid_repr(oid))
-            self._log.error(msg)
+            self._log.error(msg,exc_info=True)
             raise ConnectionStateError(msg)

@@ -734,7 +734,7 @@
             self._log.error("Couldn't load state for %s", oid_repr(oid),
-                            exc_info=sys.exc_info())
+                            exc_info=True)

     def _setstate(self, obj):

(the second bit should happen anyway ;-) )

Once this is done, how does it wend its way into a Zope 2.8 release?
What other branches / changes.txt files should I merge to?



Simplistix - Content Management, Zope & Python Consulting
           - http://www.simplistix.co.uk
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to