[ZODB-Dev] Weird errors with Zope 2.7.7

[Tim Peters]

[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[20]
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]
20
>>> tree[20] = 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.)