Configuration du service de cache dynamique dans cachespec.xml

Le service de cache dynamique est un système de mémoire cache interne doté d'une fonction de déchargement sur le disque. Les objets mis en cache sont définis dans le fichier cachespec.xml.

Vous trouverez cachespec.xml dans l'archive d'application Web (WAR), le répertoire WEB-INF du module Web ou le répertoire WEB-INF du bean d'entreprise. La version du service Elasticsearch Query du fichier se trouve dans /opt/WebSphere/Liberty/usr/servers/default/apps/search-query.ear/search-query.war/WEB-INF/cachespec.xml. Vous pouvez modifier n'importe quelle version du fichier, mais la version du service Query n'est pas automatiquement conservée via les mises à jour du conteneur Docker. Vous devez gérer manuellement cette version pour conserver les modifications que vous y apportez.

Un fichier cachespec.xml global peut également être placé dans le répertoire des propriétés de serveur d'applications, mais la méthode recommandée consiste à placer le fichier de configuration de cache avec le module de déploiement. Le répertoire WAS_installdir/properties contient un fichier de configuration de cache (cachespec.sample.xml). Le fichier cachespec.dtd est, quant à lui, disponible dans le répertoire des propriétés du serveur d'applications. Les sections suivantes décrivent en détail les étapes nécessaires pour configurer la mise en cache dynamique dans le fichier cachespec.xml.

Activation du service de cache dynamique

Dans l'environnement de production, le service de cache dynamique et la mise en cache de servlet sont tous les deux activés par défaut. Si vous activez la mise en cache dynamique dans l'environnement de création, vous risquez de rencontrer des invalidations manquées et vous n'aurez pas accès au mode de prévisualisation dont vous disposez dans l'environnement de production. En outre, dans le cas du service Elasticsearch Query, baseCache n'est activé que pour l'environnement de production. Pour plus d'informations sur ce paramètre, voir Intégration de HCL Commerce version 9 avec WebSphere eXtreme Scale.

HCL Commerce DeveloperRemarque : La mise en cache du servlet est désactivée dans l'environnement de développement. Pour activer et utiliser la mise en cache de servlet, voir Activation du service de cache dynamique et mise en cache de servlet.

Définition des éléments d'entrée de cache

L'élément racine du fichier cachespec.xml, <cache>, contient des éléments <cache-entry>. Le service de cache dynamique WebSphere analyse le fichier cachespec.xml lors du démarrage du serveur et extrait un jeu de paramètres de configuration de chaque élément <cache-entry>.

Définition des règles de génération d'ID de cache

Lorsque le service de cache dynamique place des objets en mémoire cache, il les désigne via des chaînes d'identification uniques (ID de cache) générées en fonction des règles <cache-id> spécifiées dans les éléments <cache-entry>. Lorsqu'un objet doté d'un ID de cache particulier se trouve en mémoire cache, une requête concernant un objet portant le même ID de cache est envoyée par la mémoire cache. Les règles <cache-id> définissent comment générer des ID de cache à partir des informations associées à une requête de serveur d'applications, tout en définissant la façon dont on peut obtenir les informations par voie de programme à partir des objets CacheableCommand.

  • Chaque élément <cache-entry> peut spécifier plusieurs éléments <cache-id> pour définir plusieurs règles de génération d'ID de cache. Ils sont exécutés dans l'ordre dans lequel ils apparaissent dans l'élément <cache-entry> jusqu'à ce qu'une règle génère un ID de cache valide ou que toutes les règles soient exécutées.
  • Si aucune des règles de génération d'ID de cache ne génère d'ID de cache valide, l'objet n'est pas mis en mémoire cache.
  • Chaque élément <cache-id> définit une règle pour la mise en cache d'un objet et se compose des sous-éléments <component>, <timeout>, <priority> et <property>.
  • Le sous-élément <component> peut apparaître plusieurs fois dans l'élément <cache-id> . Chaque fois qu'il indique comment générer un composant d'un ID de cache. Il existe plusieurs types d'élément de composant (parameter, session, attribute, locale, method et field).
Le tableau suivant répertorie les attributs de requête :
Attributs de requête Description
DC_curr Devise préférée de l'utilisateur
DC_lang Langue préférée de l'utilisateur
DC_porg Organisation parente de l'utilisateur
DC_cont Contrat en cours de l'utilisateur
DC_mg Groupes de membres explicites de l'utilisateur
DC_storeId Identificateur de magasin
DC_userId Identificateur de l'utilisateur
s Contrats admissibles de l'acheteur (uniquement applicable au modèle commercial de la chaîne d'approvisionnement)

Les sous-éléments <timeout>, <priority> et <property> peuvent être utilisés pour contrôler l'expiration des entrées de cache, la règle d'éviction de la cache et d'autres propriétés génériques concernant un objet mis en cache avec un identificateur généré par son élément <cache-id> conteneur. Pour plus d'informations sur l'élément <cache-id> et ses sous-éléments, voir la rubrique cachespec.xml.

L'exemple de <cache-entry> suivant utilise un élément <cache-id> pour mettre en cache les résultats créés par un JSP et générer un ID de cache avec deux composants, "storeId" et "catalogId", obtenus à partir de paramètres de l'objet de la requête :

<cache-entry>
        <class>servlet</class>
        <name>/ToolTech/. .
./StoreCatalogDisplay.jsp</name>
        <property
name="save-attributes">false</property>
        <property name="store-cookies">false</property>
        <timeout>3600</timeout>
        <priority>3</priority>
        <cache-id>
                <component id="storeId" type="parameter">
                        <required>true</required>
                </component>
                <component id="catalogId" type="parameter">
                        <required>true</required>
                </component>
        </cache-id>
...
</cache-entry>

Définition des règles de génération des ID de dépendance et des ID d'invalidation

Les éléments d'ID de dépendance permettent de spécifier des identificateurs de groupes de cache supplémentaires associant plusieurs entrées de cache sous le même identificateur de groupe.

Les ID de dépendance sont générés par concaténation de la chaîne de base d'ID de dépendance avec les valeurs renvoyées par ses éléments de composant. Si un composant requis renvoie une valeur de type NULL, les ID de dépendance ne sont pas générés et ne sont pas utilisés. Vous pouvez valider les ID de dépendance explicitement via l'interface de programmation d'application de cache dynamique WebSphere ou utiliser un autre élément <invalidation> d'entrée de cache. Les ID de dépendance sont essentiels car l'invalidation ne peut pas être effectuée sans eux.

Les ID d'invalidation sont utilisés en dépendance avec les ID de dépendance pour supprimer les objets invalidés de la mémoire cache.

Les ID d'invalidation sont générés en accord avec les règles spécifiées par les éléments <invalidation> dans les éléments <cache-entry>. Lorsqu'une requête correspondant à un élément <cache-entry> est reçue, les ID d'invalidation associés générés sont mis en correspondance avec les ID de dépendance préalablement associés aux objets en mémoire cache. Les objets en mémoire cache dont l'ID de dépendance associé est identique à l'un des ID d'invalidation générés sont invalidés.

Chaque élément <cache-entry> peut contenir plusieurs éléments <invalidation>. Chaque élément <invalidation> provoque la génération d'un ID d'invalidation en cas de réception d'une requête correspondant à son élément <cache-entry>.

Chaque ID d'invalidation est généré par concaténation de sa chaîne de base d'ID d'invalidation avec les valeurs (chacune préfixée par le signe deux points (":")) renvoyée par ses sous-éléments <component>. Si un composant requis renvoie une valeur de type NULL, l'ID d'invalidation généré dont il fait partie est supprimé.

L'exemple <cache-entry> suivant définit un élément <invalidation> pour générer un ID d'invalidation, "catalogId", lors de l'exécution de la commande CatalogUpdateCmdImpl :


<cache-entry>
        <class>command</class>
               
<name>com.ibm.commerce.catalogmanagement.commands.CatalogUpdateCmdImpl</name>
        <invalidation>catalogId
                <component id="catalogId" type="parameter">
                        <required>true</required>
                </component>
        </invalidation>
</cache-entry>

Dans cet exemple, lors de la réception de la requête d'exécution de la commande spécifiée com.ibm.commerce.catalogmangement.commands.CatalogUpdateCmdImpl avec les paramètres, l'ID d'invalidation généré est "catalogId:10010". Tout objet en cache associé à un ID de dépendance possédant la valeur à invalider est supprimé de la mémoire cache.

Mise en cache et service Elasticsearch Query

La mise en cache dynamique est activée par défaut pour le service Elasticsearch Query, dans l'environnement opérationnel uniquement. Ne l'activez pas pour l'environnement de création, car vous risquez de rencontrer des invalidations manquées et vous n'aurez pas accès au mode de prévisualisation dont vous disposez dans l'environnement opérationnel.