Re: [ZODB-Dev] Invalidating caches for module refresh doesn't seem to work
Philipp von Weitershausen wrote at 2007-1-29 23:46 +0100: After refreshing a product, Zope 2 uses the following stanza in App.RefreshFuncs.autoRefresh() to let the ZODB know that it should invalidate its pickle caches: ... refresh products from ZODB import Connection Connection.resetCaches() In fact, the lines above should be already sufficient. ... Testing product refresh with both Zope 2.9 and 2.10 produces errors for me while Zope 2.8 works, which leads me to the assumption that a cache invalidation bug was introduced after ZODB 3.4. Is anybody else seeing this? I'm a bit surprised nobody else has complained about this so far... Lots of people have complained that refreshing stopped working in Zope 2.9. Unfortunately, this is incomprehensible. After resetCaches(), the next _setDB operation (which happens as part of each DB.open()), will delete the old cache and create a new one. This means that all objects need to get loaded from the storage and in constructing them, the new classes must be used (as the old ones are no longer in sys.modules). Thus, we have a few possibilities: * the resetCaches() no longer ensures that the cache is deleted and a new one created * _setDB is no longer called in DB.open() * for some reasons, the old modules are still in sys.modules. -- Dieter ___ 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
Re: [ZODB-Dev] Invalidating caches for module refresh doesn't seem to work
On Jan 29, 2007, at 5:46 PM, Philipp von Weitershausen wrote: After refreshing a product, Zope 2 uses the following stanza in App.RefreshFuncs.autoRefresh() to let the ZODB know that it should invalidate its pickle caches: ... refresh products from ZODB import Connection Connection.resetCaches() transaction.commit() jar._resetCache() transaction.begin() That is really weird code. It looks very brittle. That way, persistent objects will use the newly reimported classes instead of continuing to use the old, no longer current classes. I suppose that was the intent. For grok I tried to implement the same mechanism and copied that code almost verbatimly, only to find out it doesn't seem to work. Persistent objects will still be instances of the classes that should have been thrown away during the re-import of modules. Testing product refresh with both Zope 2.9 and 2.10 produces errors for me while Zope 2.8 works, which leads me to the assumption that a cache invalidation bug was introduced after ZODB 3.4. Is anybody else seeing this? The way that connections were managed changes quite a bit in 3.4. I'm a bit surprised nobody else has complained about this so far... Maybe people finally stopped using product-refresh because it doesn't work reliably. Help with tracking this down would be greatly appreciated. Shane originally wrote this. Maybe he could help out. I'm not interested myself. In fact, I'l be happy to see this code get ripped out. If it stays in it needs a doctest to prevent future regression and to explain how to use it, including what it's semantics and limitations are. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ 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
[ZODB-Dev] Invalidating caches for module refresh doesn't seem to work
After refreshing a product, Zope 2 uses the following stanza in App.RefreshFuncs.autoRefresh() to let the ZODB know that it should invalidate its pickle caches: ... refresh products from ZODB import Connection Connection.resetCaches() transaction.commit() jar._resetCache() transaction.begin() That way, persistent objects will use the newly reimported classes instead of continuing to use the old, no longer current classes. For grok I tried to implement the same mechanism and copied that code almost verbatimly, only to find out it doesn't seem to work. Persistent objects will still be instances of the classes that should have been thrown away during the re-import of modules. Testing product refresh with both Zope 2.9 and 2.10 produces errors for me while Zope 2.8 works, which leads me to the assumption that a cache invalidation bug was introduced after ZODB 3.4. Is anybody else seeing this? I'm a bit surprised nobody else has complained about this so far... Help with tracking this down would be greatly appreciated. -- http://worldcookery.com -- Professional Zope documentation and training Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5 ___ 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
