IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Caching artifacts from the WebSphere Service Registry and Repository

IBM® Integration Bus saves the data 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 Broker 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 broker starts, by using the queries described here.

Configuring the WSRR Cache

The cache is configured individually for each broker by using the IBM Integration Explorer or the mqsichangeproperties command; for details, see Configurable services properties.

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 broker starts, or when a message flow containing 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 separated by semicolons, each with an optional depth specification. The user trace shows the WSRR XPath query expression 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 time has elapsed. 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 appropriately 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 occurring 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 a relevant query is issued by a WSRR node.


ac56270_.htm | Last updated Friday, 21 July 2017