Invalidación de memoria caché en la infraestructura de mandatos de BOD

A diferencia de los servicios de obtención (Get), que no efectúan cambios en los objetos de negocio, los servicios de cambio, proceso y sincronización cambiarán los objetos de negocio dentro del sistema y es posible que necesiten invalidar representaciones existentes en la memoria caché de los objetos de negocio a los que prestan servicio. Por ejemplo, cuando se modifica una entrada de catálogo determinada, es necesario invalidar cualquier JSP o servicio almacenado en la memoria caché que haga referencia a dicho objeto. Cuando se utiliza la infraestructura de mandatos de BOD con una herramienta como, por ejemplo, el Centro de gestión, o se está realizando una integración con sistemas externos, es necesario realizar políticas de invalidación de nombre y relacionadas con el nombre. Cuando se utiliza la infraestructura de mandatos de BOD con un escaparate, es necesario aplicar políticas de invalidación de mandatos de servicio para invalidar las vistas en el escaparate.

Invalidación del nombre

Como parte de los mandatos de controlador de cambio, sincronización y proceso, se puede establecer un atributo llamado uniqueIDXPath. Este atributo forma parte de una propiedad que se puede definir en el mandato que indica la vía de acceso para encontrar el ID exclusivo de los nombres que se han cambiado como parte de esta solicitud. Este atributo de mandato se utiliza a efectos de almacenamiento en memoria caché para resolver el identificador de los objetos implicados en la petición.

El atributo uniqueIDXPath se utiliza cuando se llama al método getUniqueID(). La finalidad del método getUniqueID() es devolver una colección de identificadores internos del objeto que estén implicados en la solicitud de servicio. En el caso de Cambio, Proceso y Sincronismo, son los objetos que han cambiado y requieren invalidación.

De forma alternativa, los mandatos del controlador de servicio BOD pueden ampliar el método getUniqueID() e implementarlo para devolver una Colección de ID exclusivos que represente los nombres que se cambiaron como parte de la petición actual. Este enfoque requiere cambios en la codificación y no potencia la configuración de las propiedades que pueden establecerse en un mandato.

Establecimiento del atributo UniqueID XPath

El registro de mandatos de los controladores de servicios BOD se encuentra en la tabla CMDREG. Este registro de base de datos contiene la implementación con la que está asociada la interfaz. Junto con esta asociación, se puede utilizar la columna PROPIEDADES para establecer propiedades predeterminadas en el mandato cuando se crean instancias para el mismo. Para realizar la invalidación de la memoria caché, cualquier mandato del controlador de servicio BOD que amplíe los mandatos de extracto de servicio BOD, puede tener establecida esta propiedad de forma que se pueda registrar para generar peticiones de validación cuando se realicen cambios en nombres específicos.

Se puede utilizar el siguiente SQL para actualizar las propiedades del mandato para que especifique la XPath donde se puede encontrar el ID exclusivo de los nombres de la solicitud.

update CMDREG set properties = properties || '&uniqueIDXPath;=NounIdentifier/UniqueID' 
where interfacename = 'bod service command controller interface'

Creación de la política de invalidación de nombres

Una vez que el mandato ha devuelto una colección del ID exclusivo de los nombres que han cambiado como resultado de la petición, el cachespec.xml que define el almacenamiento en memoria caché y la invalidación de memoria caché debe configurarse para crear la política de invalidación. Aunque no es necesario, se recomienda que el cachespec.xml de cada módulo de servicio esté ubicado en el módulo web HTTPInterface que corresponda a ese módulo de servicio.

Del mismo modo que para definir una política de almacenamiento en memoria caché para un mandato de servicio Get, el identificador de invalidación consta de la denominación del nombre y del ID exclusivo que se invalidan. Esta política de invalidación se configura como cualquier entrada de mandato de memoria caché con las siguientes directrices adicionales.

La propiedad delay-invalidations se establece en true. Esto se hace para asegurar que la invalidación se produce después de que el mandato se ejecute para asegurarse de que los ID exclusivos se han resuelto.
El método para la invocación es getUniqueID y el atributo multipleIDs se establece en true. Como getUniqueID devuelve una colección de ID exclusivos (UniqueID), el atributo multipleIDs (ID múltiples) creará una clave de invalidación para cada elemento de la colección devuelta.

El siguiente XML es un ejemplo de política de invalidación creada para ChangeCatalogEntryCmdImpl:

<cache-entry>
	<class>command</class>
	<name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryCmdImpl</name>
	<name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogEntryCmdImpl</name>
	<property name="delay-invalidations">true</property>
	<invalidation>CatalogEntry
		<component id="getUniqueID" type="method" multipleIDs="true">
			<required>true</required>		
		</component>
	</invalidation>
</cache-entry>

Invalidación de nombres relacionados

Cuando se cambia un nombre, eso también puede causar cambios en nombres relacionados basados en la acción realizada. Por ejemplo, cuando se mueve una entrada de catálogo de un grupo de catálogos a otro, no solo es necesario invalidar la entrada de catálogo sino que también es necesario invalidar los nombres del grupo de catálogos padre nuevo y antiguo.

Todas las acciones se presentan como mandatos de acción que realizan una acción específica en el nombre (si se trata de proceso) o en la parte de nombre (si se trata de cambio y sincronización). Estos mandatos de acción son muy específicos y normalmente estarán allí donde se realicen cambios en los nombres relacionados. Después de nuestro ejemplo, la implementación del mandato que será responsable de la invalidación del grupo de catálogos será la implementación asociada a la interfaz com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryPartCmd y a la expresión XPath /CatalogEntry[]/ParentCatalogGroupIdentifier.

Con fines de invalidación, como parte de la implementación del mandato, conservará un objeto de Colección que registre todos los nombres que hayan cambiado. La colección se devuelve mediante un método en el mandato, por ejemplo, getModifiedCatalogGroups(), que puede utilizar la política de invalidación de memoria caché. El convenio de denominación que se sugiere para estos métodos es getModifiedNounNames para declarar explícitamente los distintos nombres relacionados que quedan afectados como parte de este mandato de acción.

Creación de la política de invalidación de nombres relacionados

Cuando el mandato devuelve una colección de ID exclusivos de nombres que puede modificarse, el siguiente paso es actualizar el cachespec.xml de ese módulo de servicio con el mandato de invalidación. El cachespec.xml es el mismo que se ha utilizado para registrar la política de invalidación para los mandatos de controlador de BOD.

La política de invalidación es muy similar a la política definida para los mandatos de controlador de cambio, proceso o sincronización. Establezca la propiedad de demora de invalidación en true y el método devolverá una colección de ID exclusivos para invalidarlos en vez invalidar únicamente uno. La diferencia estriba en que el método invocado es el método getModifiedNounNames() personalizado en vez del getUniqueID genérico.

El siguiente ejemplo XML es un ejemplo de política de invalidación personalizada para un mandato de acción que cambia la relación del grupo de catálogos de un entrada de catálogo:

<cache-entry>
	<class>command</class>
	<name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryParentCmdImpl</name>	
	<property name="delay-invalidations">true</property>
	<invalidation>categoryId
		<component id="getModifiedCatalogGroups" type="method" multipleIDs="true">
			<required>true</required>		
		</component>
	</invalidation>
</cache-entry>

Cuando se trata de un método personalizado, se utiliza getModifiedCatalogGroup para invalidar grupos de catálogos relacionados.

Reglas de invalidación de mandatos SOA de catálogo para todas las tiendas

El siguiente es un ejemplo de cómo establecer las reglas de invalidación para los nuevos mandatos SOA de catálogo para todas las tiendas. Para utilizar estas reglas, las entradas de la memoria caché definen en este archivo la necesidad de fusionarse en el archivo cachespec.xml para almacenar en la memoria caché fragmentos y páginas JSP.

Nota: El siguiente fragmento de código está contenido en el archivo WCDE_installdir\samples\dynacache\invalidation\catalog\cachespec.xml. Sin embargo, este archivo no se puede utilizar directamente, ya que no contiene el elemento de memoria caché.


<!-- This list of unique IDs is to indicate which Catalog nouns have been involved with the change/process -->
<!-- request and requires to be invalidated.                                                               -->

<cache-entry>
       <class>command</class>
       <name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogCmdImpl</name>
  <name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogCmdImpl</name>
       <property name="delay-invalidations">true</property>
       <invalidation>catalogId
              <component id="getUniqueID" type="method" multipleIDs="true">
                     <required>true</required>              
              </component>
       </invalidation>
</cache-entry>

<!-- This list of unique IDs is to indicate which CatalogGroup nouns have been involved with the change/process                        -->
<!-- request and requires to be invalidated.                                                                                           -->
<!-- The catalog id can be used to invalidate related pages when a catalog group is updated.                                           -->
<!-- For example, when the name of a category is renamed (categoryId=50400000003), the CategoryDisplay page for this category needs to -->
<!-- invalidate:                                                                                                                       -->
<!-- CategoryDisplay?catalogId=504&categoryId=50400000003                                                                              -->
<!-- Since the CategoryDisplay pages for its parent category (categoryId=50400000013) and sibling categories (categoryId=50400000014)  -->
<!-- also display the name of the category, they also need to invalidate.                                                              -->
<!-- CategoryDisplay?catalogId=504&categoryId=50400000013                                                                              -->
<!-- CategoryDisplay?catalogId=504&categoryId=50400000014                                                                              -->

<cache-entry>
       <class>command</class>
       <name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogGroupCmdImpl</name>
  <name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogGroupCmdImpl</name>
       <property name="delay-invalidations">true</property>
       <invalidation>categoryId
              <component id="getUniqueID" type="method" multipleIDs="true">
                     <required>true</required>              
              </component>
       </invalidation>
       <invalidation>catalogId
                     <component id="getCatalogId" type="method">
                            <required>true</required>
                     </component>
       </invalidation>
</cache-entry>

<!-- This list of unique IDs is to indicate which CatalogEntry nouns have been involved with the change/process -->
<!-- request and requires to be invalidated.                                                                    -->
       
<cache-entry>
       <class>command</class>
       <name>com.ibm.commerce.catalog.facade.server.commands.ChangeCatalogEntryCmdImpl</name>
  <name>com.ibm.commerce.catalog.facade.server.commands.ProcessCatalogEntryCmdImpl</name>
       <property name="delay-invalidations">true</property>
       <invalidation>productId
              <component id="getUniqueID" type="method" multipleIDs="true">
                     <required>true</required>              
              </component>
       </invalidation>
</cache-entry>

Ejemplo de invalidación de catálogo

Copie los contenidos del archivo WCDE_installdir\samples\dynacache\invalidation\catalog\cachespec.xml al final del archivo WAS_installdir\profiles\instance_name\installedApps\cell_name\WCServer_enterprise_archive\Stores.war\WEB-INF\cachespec.xml que precede inmediatamente al elemento </cache>.

En las tiendas de inicio no se muestra cómo invalidar los nombres relacionados. Por ejemplo, si se cambia un nombre de producto, la página de detalles de producto queda invalidada, pero no la página de categoría que contiene el nombre del producto. Puede invalidar los objetos de memoria caché relacionados utilizando estos enfoques:

Invalidación basada en tiempo
Este enfoque es fácil de implementar, pero algunas entradas podrían quedar obsoletas durante un periodo de tiempo. Para obtener un ejemplo, consulte la entrada MiniShopCarDisplay.jsp del archivo cachespec.xml de la tienda de inicio Madisons. Para obtener más información, consulte Invalidación basada en tiempo, en el tema Invalidación de memoria caché.
Desencadenantes de base de datos en la tabla CACHEIVL
Para obtener información, consulte Invalidación de API Dynacache y tabla CACHEIVL en el tema Invalidación de memoria caché.
El código Java personalizado para emitir mensajes de invalidación utilizando las API Dynacache.
Este enfoque requiere tener buenos conocimientos de las API Dynacache. Para obtener información, consulte IBM WebSphere Application ServerTM, Release 7 API Specification: Dynacache API and Mastering DynaCache in HCL Commerce.