Views: 454 (Data available since 06.02.2017)
Last Modified: 18.09.2014
Starting from the main module of version 9.1.0, cache tags are supported. Cache can be marked with tags and reset also by tags. The cache of the infoblock components can be reset when the information contained in them changes.
Note. For large data amount that are often updated, tagged caching is not justified.
Cache Tagging Base Code:
01: $cache_id = md5(serialize($arParams));
02: $cache_dir = "/tagged_getlist";
04: $obCache = new CPHPCache;
05: if($obCache->InitCache(36000, $cache_id, $cache_dir))
07: $arElements = $obCache->GetVars();
09: elseif(CModule::IncludeModule("iblock") && $obCache->StartDataCache())
11: $arElements = array();
12: $rsElements = CIBlockElement::GetList($arParams["order"], $arParams["filter"]);
14: global $CACHE_MANAGER;
16: while($arElement = $rsElements->Fetch())
19: $arElements = $arElement;
28: $arElements = array();
Line 01 initializes the unique cache file identifier. Then, the catalog is defined from
/bitrix/cache where the cache files are stored with different values of $arParams. It is important that this path start from slash but not end with it. When using memcached or APC as the cache it will be of critical importance for the cache reset.
Lines 04-05 initialize the cached object. If the caching time is not expired, line 07 will be executed and we will obtain the data from the cache file.
The condition in line 09 will be true nearly always. Here, the module is connected and caching starts.
Line 12 provides for a database query. It is important that all of the parameters on which a selection result depends “participate” in the cache identifier ($cache_id).
In line 14, the access to the variable $CACHE_MANAGER. is set. This object will control tags.
Line 15 – all subsequently allocated tags will be bound to the catalog $cache_dir. When the cache is reset in one of them, the contents of this catalog will be deleted. StartTagCache may be used recursively. For example:
It is important that the calls StartTagCache and EndTagCache are balanced. The object $CACHE_MANAGER creates and tracks the stack of cache catalogs. In this case, the tags allocated for the catalog $cache_dir3 áwill also be connected with $cache_dir2 and $cache_dir1. The tags allocated for cache_dir2 will be also connected with $cache_dir1.
Line 18 provides for tagging the cache by using the method RegisterTag. The body length may not exceed 100 characters. Tag duplicates are deleted automatically when the RegisterTag method is used.
Line 22 writes catalog tags to the database table. The count is one insert per tag.
To launch the mechanism, a constant in the file dbconn.php must be defined.
If the method StartResultCache is used, the entry will be retrieved by StartTagCache with a path to the component cache (depending on the page).
If the method EndResultCache is used (which, in its turn, is retrieved from IncludeComponentTemplate) - by EndTagCache.
In the infoblock module CIBlockElement::GetList and CIBlockSection::GetList return the object of the CIBlockResult class.
The method Fetch/GetNext of this object will retrieve
If the selection does not contain any elements, the value of the infoblock identifier will be retrieved from the filter.
Cache reset is called from the methods Add/Update/Delete for elements, sections, and infoblocks. When the properties are changed, for example, using SetPropertyValueCode there will be no flushing. In this case, the following code can be used to clear cache:
The use of this tagged cache mechanism is not recommended in case of the frequent update of elements or sections. On the other hand, it must be convenient for content managers: all changes are immediately displayed on the website.