Caching artifacts from the WebSphere Service Registry and Repository

IBM® App Connect Enterprise saves the data that it retrieves from the WebSphere® Service Registry and Repository (WSRR) in a local cache.

The WSRR nodes, EndpointLookup and RegistryLookup, can retrieve data that was stored in the Integration node WSRR cache by a previous query, improving performance and message throughput. The first occurrence of each query is always sent to WSRR. By default, this activity occurs when a WSRR node first issues a specific query, although it is possible to pre-populate the cache, when the integration node or integration server starts, by using the queries described here.

Configuring the WSRR Cache

The cache is configured individually for each integration node or independent integration server by editing the parameters in the .conf.yaml configuration file; for more information, see Configuration parameters for the WebSphere Service Registry and Repository nodes.

You can configure the cache in the following ways:
  • Disabling the cache

    Disable the cache by setting the needCache parameter to false. By default, the cache is enabled, but the WSRR nodes can operate without the cache. If the cache is disabled, every query that is issued by the node is sent to WSRR, ensuring that the results of the query always reflect the current contents of the registry. This activity can affect performance.

  • Preloading the cache

    Preload the cache by setting the predefinedCacheQueries parameter. By default, no items are preloaded in the cache and the first occurrence of every query is sent to WSRR. You can specify predefined queries that are executed when the integration node or integration server starts, or when a message flow that contains WSRR flows is first deployed, populating the cache for use by subsequent WSRR nodes. By specifying predefined queries, performance might be affected at startup, rather than on the first occurrence of a query at run time. The predefinedCacheQueries parameter is a list of WSRR XPath query expressions that are separated by semicolons, each with an optional depth specification. The user trace shows the WSRR XPath query expression that is generated by a WSRR node.

  • Changing the cache expiry timeout value

    Change the cache expiry timeout value by setting the timeout parameter. The cached results of a query are discarded after the specified elapses. The next occurrence of the query is sent to WSRR and the new result is entered in the cache. If the contents of the registry are likely to change frequently, you can specify a shorter expiry timeout value so that changes are picked up quicker. This activity affects performance as more queries are sent to WSRR.

  • Enabling cache notification

    Enable cache notification by setting the enableCacheNotification parameter to true and by setting the initialContextFactory and locationJNDIBinding properties for your WSRR server. By default, cache notification is disabled. Cache notification is a more flexible method than expiry timeout for refreshing cached data because it allows individual WSRR entities to be refreshed at the time they are modified in WSRR.

    If cache notification is enabled, the cache subscribes to events that occur in WSRR and is notified when an object is updated or deleted in WSRR. The object is discarded from the cache. If the refreshQueriesAfterNotification parameter is set to true, the cache is updated with the new version of the object immediately. If the refreshQueriesAfterNotification parameter is set to false, the cache is updated the next time that a relevant query is issued by a WSRR node.