midcom_services_cache_module_napThis is the NAP/Metadata caching module. It provides the basic management functionality for the various backend databasese which will be created based on the root topic of the NAP trees (thus the cache can be shared between AIS and on-site pages).
The actual handling of the various db's is done with _basicnav.php and metadata.php, this class is responsible for the creation of backend instances and invalidation for both NAP and Metadata cache objects. (Which implies that it is fully aware of the data structures stored in the cache.)
All entries are indexed by their Midgard Object GUID. The entries in the NAP cache basically resemble the arrays within the basicnav node/leaf cache, while the metadata cache is a copy of the actual metadata property cache of the midcom_helper_metadata object.
NAP/Metadata caches can be shared over multiple sites, as all site specific data (like site prefixes) are evaluated during runtime.
Most of the cache update work is done in midcom_helper__basicnav, so you should look there for details about the caching strategy.
Implementation notes:
Currently, the metadata object is not cached. Instead it relies on the NAP object copies to work in a cached fashion: It uses the members of the object copy from the cache for all basic operations (using the $object->$domain_$name feature of Midgard in combination with variable variables).
Located in /midcom/services/cache/module/nap.php (line 42)
midcom_services_cache_module | --midcom_services_cache_module_nap
Array
$_backend_config
= null (line 56)
The configuration to use to start up the backend drivers. Initialized during startup from the MidCOM configuration key cache_module_nap_backend.
Internal runtime state variable.
Array
$_guid_backend_map
= array() (line 64)
This array maps GUIDs to backend instances. This is required as AIS sites use the backend instance related to the live site. See _check_for_topic() for details.
Internal runtime state variable.
Inherited from midcom_services_cache_module
midcom_services_cache_module::$_backends
midcom_services_cache_module::$_config
Module constructor, relay to base class.
Returns the NAP cache accociated with the topic tree identified by the parameter $root_topic_guid. The constructed cache database name will be "NAP_{$root_topic_guid}".
It verifies, that the cache databases related to the root topic
Invalidates all cache objects related to the GUID specified. This function is aware for NAP / Metadata caches. It will invalidate the node/leaf record pair upon each invalidation.
This function only works within the current context, because it looks on the invalidated GUID to handle the invalidation correctly.
Note, for GUIDs which cannot be resolved by NAP:
It should be safe to just skip this case, because if the object to be invalidated cannot be found, it is not cached anyway (deleted items could be resolved using the resolve_guid code which uses the cache, so they would still be found). Special cases, where objects not avaialbe through NAP are updated have to be hanlded by the component anyway.
This way, leaf deletions should be safe in all cases (if they are cached, they can still be resolved, if not, they aren't in the cache anyway). The Datamanager tries to catch leaf creations using its internal creation mode flag, invalidating the current content topic instead of the actual object in this case. Note, that this happens directly after object creation, not during the regular safe cycle.
See the automatic index invalidation code of the Datamanager for additional details.
Internal helper, which ensures that the cache databases for root topic guid passed to the function are loaded.
For compatiblity with separated AIS/on-site Page MidCOM installations, the method will load the topic from the database and map all requests to a topic which is of a midcom.admin.content type to the corresponding root content topic. Note, that this is actually a bug in the core's context seapration, which I have not yet found. Normally, all instances of basicnav should work within a on-site-context and therefore this "fallback" should not be neccessary. Unfortunalety, sometimes the context information seems to get mixed up, which results in AIS writing NAP information to the wrong cache file.
Initialization event handler.
It will load the cache backends for the current MidCOM topic.
Initializes the backend configuration.
Inherited From midcom_services_cache_module
midcom_services_cache_module::midcom_services_cache_module()
midcom_services_cache_module::initialize()
midcom_services_cache_module::invalidate()
midcom_services_cache_module::invalidate_all()
midcom_services_cache_module::shutdown()
midcom_services_cache_module::_create_backend()
midcom_services_cache_module::_on_initialize()
midcom_services_cache_module::_on_shutdown()
Documentation generated on Mon, 21 Nov 2005 18:19:24 +0100 by phpDocumentor 1.3.0RC3