Cache-Controlled Z SQL Methods
Z SQL methods provide a caching mechanism that can greatly reduce the number of database accesses.
If, however, the database is changed dynamically, the cache must be used with caution as otherwise stale query results may be returned.
In many cases, there are tables that are generally non-changing, but that occassionally may be changed, and, when they are, the designer would prefer that Zope releases the cached version, rather than waiting for it to expire naturally. Cache-Controlled Z SQL Methods provide this ability.
Cache controled SQL methods (CCSQLMethod) are derived from Z SQL methods. In addition to the normal Z SQL methods, a cache controlled SQL method implements the functions flushCache() and flushCacheEntry(REQUEST=None, **kw). flushCache flushes the complete cache associated with the method. flushCacheEntry flushes the query specified by its arguments. The query is determined in the same way as in __call__. This allows explicit cache control and allows for much better cache utilization.
(If you have a habit of not reading all the contents of README files, please see the ZEO notes for flushCacheEntry below. Or you'll regret not reading everything.)
This product is a ZEO-safe update, minor modernization, and repackaging of Dieter Maurer's product of the same name.
Overview of Using Cache-Controlled Z SQL Methods
The following outlines the steps to use CCZSQLM.
- create a CCSQLMethod. These provide the same behavior and interface as a normal Z SQL Method. Choose a lengthy maximum cache period.
- Zope will cache the results for each set of query parameters and will use its cached copy, if possible, rather than requesting information from the relational database.
- When the underlying database tables change, call:
to clear the cache. This will clear the cached data from Zope for this query, and future requests from this SQL Method will generate fresh data from the database.
- Or, to clear the cache for just one set of values, call:
Having Caches Cleared Automatically
Many databases provide trigger or rule capability to execute actions when a table changes. These mechanisms can often provide the ability for the database to notify Zope when it should clear it's cache.
For example, a trigger can execute a script that uses a web request to call the flushCache method. In PostgreSQL, trigger scripts can be written in Python, Perl, C, Tcl, or other procedural languages, and the script can use native libraries to make this request, or call use a system tool like wget. For examples of how to set this up in PostgreSQL, see Using Archetypes SQLStorage, which demonstrates this technique (as part of a large HOWTO) using a call to wget.
Another interesting possibility is that you, for PostgreSQL 7.4 and newer, you can run a Zope client within PostgreSQL, and can make Zope requests directly from PostgreSQL. This technique is documented at Accessing Zope from PostgreSQL.
Working with ZEO
Cache-Controlled Z SQL Methods share a single cache across all threads of a Zope server, but under ZEO, there may be several Zope servers with different caches. This product uses a simple notification mechanism to let all of the ZEO clients know that they should flush their cache results when one of the Zope clients has been told to flush its results. This means that a flushCache() call will work against all clients for a particular ZEO server.
Important Note: Only the flushCache() method call is ZEO-safe. The flushCacheEntry() method call is not ZEO-safe, as it flushes this entry only from the cache of the Zope server that it is made against. This may change in the future, but for now, you should not use this call if you are in a ZEO environment.