[Chris Withers] > ... > Hmm.. well, I guess the clients could have restarted during the day and > so maybe it is a startup race?
If a client restarted during the day, wouldn't you find evidence of that in your logs? ... >>>> That one comes out of Connection.setstate(), and appears to mean what >>>> it says: the app is trying to load an object from this Connection but >>>> the Connection has been closed. > Hurm... Zope? Plone? Sessions? Which one shall it be today? *sigh* Any > clues greatfully received (ie: common patterns that cause this error) Try Google. Unintentional, or flawed intentional, app caching is a good candidate. I've only tracked down one of these in my life, which turned out to be unintentional caching (a non-persistent class instance unintentionally holding on to a persistent object across requests). 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'] >>> type(tree) <extension class BTrees.OOBTree.OOBTree at 00C99660> >>> cn.close() # DON'T BLINK >>> tree Traceback (most recent call last): File "<stdin>", line 1, in ? File "ZODB\Connection.py", line 587, in setstate raise RuntimeError(msg) RuntimeError: Shouldn't load state for 0x01 when the connection is closed Is that clear? `tree` there got loaded from a connection, the connection got closed, and _then_ code tried to access state reachable from `tree`. Well, it can't: the connection is no longer open to load the state from, so Connection complains. 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. This is what happens if an app tries to do that: >>> st = ZODB.FileStorage.FileStorage('Data.fs') >>> db = ZODB.DB(st) >>> cn = db.open() >>> rt = cn.root() >>> tree = rt['tree'] >>> tree 20 >>> tree = 40 # modify an object >>> cn.close() # then try to close the connection w/o commit or abort Traceback (most recent call last): File "<stdin>", line 1, in ? File "ZODB\Connection.py", line 306, in close raise ConnectionStateError("Cannot close a connection joined to " ZODB.POSException.ConnectionStateError: Cannot close a connection joined to a transaction Of course it's possible that some app code you're using suppresses ConnectionStateError too. If not, "unintentional caching" is a good bet. 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.) _______________________________________________ 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