<div>Thanks for your quick reply!</div><div><br></div>So, the best place to call those would be during my commit break (whenever I decide to take it? [which would be less often if I could be sure of no crashing]). Are there any other problems with the way I was using ZODB in my code? I really like it, but I recognize that it's a lot more complicated than my old system.<div>
<br></div><div>Cheers,</div><div>Ryan<br><br><div class="gmail_quote">On Mon, May 10, 2010 at 12:48 PM, Alan Runyan <span dir="ltr"><<a href="mailto:runyaga@gmail.com">runyaga@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">> The DB on the choked process is perfectly good up to the last commit when it<br>
> choked, and I've even tried extremely small values of cache_size_bytes and<br>
> cache_size, just to see if I can get it to stop allocating memory and<br>
> nothing seems to work. I've also used string values ('128mb') for<br>
> cache-size-bytes, etc.<br>
<br>
</div>On the connection object there are two methods you want to use:<br>
- cacheMinimize<br>
This is more of a heavy hand which attempts to deactive *all* non<br>
modified objects from cache.<br>
<br>
- cacheGC<br>
This will clean up the internal cache via the cache-byte-size parameter.<br>
<br>
If you are not calling these (I do not believe they are called in trnx.commit)<br>
in your code; then they are probably not being called.<br>
<br>
cheers<br>
<font color="#888888">alan<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Ryan Noon<br>Stanford Computer Science<br>BS '09, MS '10<br>
</div>