Re: Re: closed connection during Zope2 request
Vincent Pelletier <[email protected]>
| Newsgroups | gmane.comp.web.zope.zodb |
|---|---|
| Message-ID | <[email protected]> |
On Fri, 30 Sep 2016 14:32:28 +0000, Mauro Amico <[email protected]> wrote: > File "/opt/cache/buildout/eggs/zope.tal-3.5.2-py2.7.egg/zope/tal/ > talinterpreter.py", > line 182, in __init__ > self.program = program > File "/opt/cache/buildout/eggs/Zope2-2.13.23-py2.7.egg/App/ZApplication.py", > line 84, in __del__ > self._jar.close() > File "/opt/cache/buildout/eggs/ZODB > 3-3.10.5-py2.7-linux-x86_64.egg/ZODB/Connection.py", > line 384, in close > self.setDebugInfo("%s" % traceback.format_stack()) Maybe it is obvious to you already, but I did not see it mentioned yet: object actual destruction happens a "long" time after it was requested, when the python garbage collector decides to check what it has to do. So as long as you see __del__ in the traceback, anything above it is basically meaningless. The stack trace from "Shouldn't load state for" is likely much more relevant, showing you code very close to the point where you are accessing the bad object. Note that such invalid accesses are only detected when the ZODB actually gets involved: the object could be accessed without errors moments before, and would just fail here because it would have been ghost-ified (ie, its __dict__ emptied) as ZODB would have tried to make room for more objects in the cache. Then, upon attribute access, the ZODB will try to load the object state, and here detects that it's not supposed to be doing that anymore. I believe that if the same connection was re-opened at that time (because your server is busy and the connection was reopened by a concurrent request), the issue can be hidden: the connection will think it is legitimate to load that object's state, without knowing it is being used from an unintended transaction. And of course, it would violate transaction isolation. As a less likely variant of what Jens said, you could also be "leaking" a connection instead of/in addition to "leaking" persistent objects outside of their connection's life. In which case you would have one more indirection to follow: an apparently innocent object raises the exception because it was retrieved from the wrong connection, because that connection would be used just a bit before being automatically closed but after its request would have ended. -- Vincent Pelletier -- You received this message because you are subscribed to the Google Groups "zodb" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.