[old thread from december]

Dieter Maurer wrote:
Chris Withers wrote at 2005-12-14 16:23 +0000:
...
  File "lib/python/ZODB/Connection.py", line
788, in _setstate_noncurrent
    assert end is not None
AssertionError


This means that the latest modification for this object
lies before the respective transaction.

In this case, we should not have an invalidation for the object,
such that we would not call "_setstate_current".

I expect a missing "flush_invalidations" during "Connection._setDB".
I had to add such a call in our ZODB version:

    def _setDB(self, odb, mvcc=None, txn_mgr=DEPRECATED_ARGUMENT,
               transaction_manager=None, synch=None):
        ....
        self.transaction_manager = transaction_manager or transaction.manager
        # DM 2005-08-22: always call '_flush_invalidations' as it does
        #  more than cache handling only
        self._flush_invalidations()
        if self._reset_counter != global_reset_counter:
            # New code is in place.  Start a new cache.
            self._resetCache()
        # DM 2005-08-22: always call '_flush_invalidations'
##        else:
##            self._flush_invalidations()


Hi Dieter,

This patch didn't seem to cure our Zope 2.8 afflicted with the "assert end is not None" problem. Could you expand a bit on why you think it would matter? From what I understand of the code, it would only come into play during a refresh() operation. Could you expand on the "it does more than cache handling"? Invalidations being synchronous,

BTW do you have other patches in your local patched ZODB? I'm willing to look at all of them and see if they can be integrated.

Thanks,
Florent

--
Florent Guillaume, Nuxeo (Paris, France)   Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   [EMAIL PROTECTED]
_______________________________________________
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

Reply via email to