[ZODB-Dev] ZEO/Zope unexpected behaviour

[Toby Dickenson]

I have just upgraded one zeo-based zope cluster from zope 2.4.x to the 
current CVS. Some intermediate version has added the need for a temp_folder 
object in Zopes root folder; this object is added if needed in 
OFS.Application.initialize.

This cluster has three zope clients. Everything was as expected when bringing 
up the first client. However strange things happened when bringing up 
the second and third clients.

When bringing up the second client, I saw the following traceback:
2002-03-18T13:35:15 PANIC(300) z2 Startup exception
Traceback (innermost last):
  File /home/cedarmaster/app2/Zope2/z2.py, line 526, in ?
  File <string>, line 1, in ?
  File 
/home/cedarmaster/replicated/versions/Zope-day1/lib/python/Zope/__init__.py, 
line 71, in ?
  File 
/home/cedarmaster/replicated/versions/Zope-day1/lib/python/OFS/Application.py, 
line 273, in initialize
    (Object: Zope)
  File 
/home/cedarmaster/replicated/versions/Zope-day1/lib/python/ZODB/Transaction.py, 
line 238, in commit
  File 
/home/cedarmaster/replicated/versions/Zope-day1/lib/python/ZODB/Connection.py, 
line 280, in commit
ConflictError: database conflict error (oid 0000000000000001, class 
OFS.Application.Application)

It appears that this second Zope client believed the root folder still did 
not contain the temp_folder object. I assume it was using and old version of 
the root folder object from its client cache. This is confirmed by trying 
bring this client up for a second time: everything works, because the first 
ConflictError has removed the object from the client cache.

Some questions:

1. Should this startup code catch ConflictError and retry? I guess ideally it 
should, but I dont see any major problem to not doing so.

2. Doesnt ClientStorage validate every object in its cache before allowing 
any data methods to be called (provided wait_for_server_on_startup is not 
unset) ? Have I misunderstood how this is supposed to work? Is it worth me 
investigating further?