[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
