Re: [ZODB-Dev] [Warning] potential ZODB cache inconsistency after client reconnect
On Aug 15, 2006, at 2:32 PM, Jim Fulton wrote: On Jun 12, 2006, at 1:35 PM, Dieter Maurer wrote: Sorry to take so long to get to this Jim Fulton wrote at 2006-6-12 06:34 -0400: ... The potential inconsistency occurs because the ZODB (Connection) cache may contain objects not in the ZEO client cache. Even if invalid meanwhile, they are not checked and invalidated during the cache verification phase. If true, that would be a serious bug. In _process_invalidations, the invalidations are passed on to the database, which passes then on to the connections. What makes you think this isn't happening? This happens -- but only for objects the ZEO client cache knows about. The problem is with objects that are in a Connection cache but not in a ZEO client cache (because this is too small, for example). The storage does not know about them and therefore does not check with the server whether they are still valid. Ah, good point. Hm. I suppose a conservative strategy would be to clear the connection caches when the storage reconnects. I'll look into doing that. I've implemented this on the 3.7 branch and on the trunk. 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
Re: [ZODB-Dev] [Warning] potential ZODB cache inconsistency after client reconnect
On Jun 12, 2006, at 1:35 PM, Dieter Maurer wrote: Sorry to take so long to get to this Jim Fulton wrote at 2006-6-12 06:34 -0400: ... The potential inconsistency occurs because the ZODB (Connection) cache may contain objects not in the ZEO client cache. Even if invalid meanwhile, they are not checked and invalidated during the cache verification phase. If true, that would be a serious bug. In _process_invalidations, the invalidations are passed on to the database, which passes then on to the connections. What makes you think this isn't happening? This happens -- but only for objects the ZEO client cache knows about. The problem is with objects that are in a Connection cache but not in a ZEO client cache (because this is too small, for example). The storage does not know about them and therefore does not check with the server whether they are still valid. Ah, good point. Hm. I suppose a conservative strategy would be to clear the connection caches when the storage reconnects. I'll look into doing that. 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] [Warning] potential ZODB cache inconsistency after client reconnect
I fear we may get a ZODB cache inconsistency after a client disconnect. The current reconnection protocol essentially works as follows: * ClientStorage detects a broken ZEO connection and starts a reconnect thread * The reconnect thread tries to reconnect to the ZEO server and starts (ZEO client) cache verification, when it succeeds. * All no longer valid oid, version, tid entries are invalidated in the client and ZODB (Connection) caches. The potential inconsistency occurs because the ZODB (Connection) cache may contain objects not in the ZEO client cache. Even if invalid meanwhile, they are not checked and invalidated during the cache verification phase. -- 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
