<br><tt><font size=2>Gary Poster <gary@zope.com> wrote on 07/31/2008
01:07:39 PM:<br>
<br>
> I'm the primary zc.catalog author.<br>
> <br>
> He is running read-only, so savepoints shouldn't be very pertinent.<br>
> <br>
> The original poster is correct that the cache is cleaned out at <br>
> transaction boundaries (or savepoints, as Alan said).<br>
> <br>
> I don't have experience with running the db in readonly mode in <br>
> production. That said, if you have obvious boundaries for your
<br>
> searches, I suspect that beginning a transaction at the boundary would
<br>
> probably do the trick, and also work (with invalidations and the like)
<br>
> if you ever have a readonly connection to a ZEO database server that
<br>
> is getting updates from another source.<br>
> <br>
> While it's interesting to contemplate the knob that Alan mentioned,
<br>
> I'm reasonably confident that this logic belongs in the app, not the
<br>
> index or catalog.<br>
</font></tt>
<br><tt><font size=2> I was thinking
it this logic would be in the ZODB.DB since it (or something else in ZODB)
is already responsible for clearing out the cache at transaction boundaries,
and it should be aware the FileStorage is read_only. But it doesn't
sound like it is. Also, it sounds like the cache is not for keeping
any objects in memory to avoid rereading from disk (excepting those changed
that need to be written in the next transaction), but only to keep some
objects in memory across transaction boundaries.</font></tt>
<br>
<br><tt><font size=2> For now I've put
it into the "app" (really, a thrown-together script) to call
cacheMinimize on the DB object after dealing with the results of each search.
If we were going to stick with ZODB, I'd work on handling it in my
own code, but we're moving away from ZODB (for managerial reasons).</font></tt>
<br>
<br><font size=2 face="sans-serif">-- <br>
Anthony Foglia<br>
Princeton Consultants<br>
(609) 987-8787 x233</font>