contributors: Shane Hathaway, Dieter Maurer, Toby Dickenson, Tim Peters
As a program proceeds, persistent objects stored in ZODB get loaded into memory. There are three broad reasons the system may decide to "unload" a persistent object again (also called "ghostifying" an object), which means to release its memory, so that the next reference to the object will load it from ZODB again:
Semantic - the cached object state is out of date
When a transaction commits, invalidations are sent to all other connections for all objects modified by the transaction. Note a subtlety: an invalidation is not sent to the connection doing the commit, because it already has up-to-date states for the objects it just changed. When a connection receives an invalidation message, it unloads the invalidated objects. XXX MVCC vs non-MVCC, etc.
Pragmatic - memory is finite, and the system wants to make room for other objects
In theory, a persistent object may be unloaded at any time.
In practice, in all implementations of ZODB to date, objects used in the current transaction are never automatically unloaded before the current transaction commits or aborts (this includes sub-transactions). The ZODB "garbage collector" runs at the end of each transaction, and may unload objects then. Its decisions are based on how many objects are then currently in the cache, how recently cached objects have been used, and the configured cache size.
User-driven - the user forces unloading
The garbage collector (perhaps under the rubric of "cache minimization") may also be invoked explicitly by application code.
If application code calls the ._p_invalidate() method on a persistent object, the
object may be unloaded (it depends on internal details of the object's state).
While ._p_invalidate() may work, ._p_deactivate() seems to do a good job of ghosting
objects without causing unintentional side effects.
Application code can do obj._p_changed = None to unload an object that hasn't been
modified; this isn't recommended.
Application code can do del obj._p_changed to unload an object even if it has been
modified; this is highly not recommended.
Finally, obj._p_jar.cacheMinimize() will ghost all objects in memory; cacheMinimize(int)
will ghost objects that have been inactive longer than int seconds.