Forced non-caching in ZODB?
Anyone know of a way to code an object such that ZODB won't cache it? I'm aware you can change cache/thread parameters, but if you have a small number of sufficiently large objects, you may end up putting the system into full thrash mode by the time you set a number low enough to make a difference. TIA for any thoughts or hints, Dylan
Dylan Reinhardt wrote at 2003-11-24 15:15 -0800:
Anyone know of a way to code an object such that ZODB won't cache it?
This is impossible. The cache is vital for consistency. Without it, you could end up with different independent copies of the same object. Non-deterministic chaos could result if these copies were modified.
I'm aware you can change cache/thread parameters, but if you have a small number of sufficiently large objects, you may end up putting the system into full thrash mode by the time you set a number low enough to make a difference.
The easiest solution is to avoid large objects (by splitting them into several smaller ones). See "OFS.Image.File" for an example. Another way is to explicitely deactivate your objects (--> "_p_deactivate"). This flushes the object from the cache, unless it was modified in the current transaction. You can use the REQUEST's "_hold" method to register things (such as deactivation of your objects) to be done when the request object is destroyed. -- Dieter
On Tue, 2003-11-25 at 12:26, Dieter Maurer wrote:
Dylan Reinhardt wrote at 2003-11-24 15:15 -0800:
Anyone know of a way to code an object such that ZODB won't cache it?
This is impossible.
I was afraid that might be the case... but I'll settle for "won't cache it for very long".
Another way is to explicitely deactivate your objects (--> "_p_deactivate").
I think that may be exactly what I was looking for. Thanks! Dylan
participants (2)
-
Dieter Maurer -
Dylan Reinhardt