Without ZEO, Zope maintains separate connections to a single "DB" object (which is the mediator between the physical storage and the rest of the system). These connections are available to a pool of threads, each which loads its own copy of the application space. When objects are read by the DB out of storage, each thread gets its own copy of the object and keeps it in an in-mem cache that is tunable and transparent. If the object becomes stale, it is invalidated in each thread by the DB instance, and needs to be reread from disk. An object hangs around in cache and reads need not hit the disk until the object is invalidated (by being written to in another thread) or by the cache being "garbage collected".
ZEO extends this model by reusing it and providing a similar invalidation scheme between distributed processes via IP.
Sorry, I can't spend much more time on this.... For more info, I'd suggest you visit zope.org or any of the links I've given in this thread.