[Enterprise Extensions only]
  Next topic

Caching to improve performance

The BRBeans framework incorporates a cache on the client side, i.e. wherever the trigger method on the TriggerPoint object is called. This cache is scoped to the JVM in which the client is running so that any trigger calls performed in a particular JVM will use the same cache, and two triggers performed in different JVMs will use two different caches. The BRBeans cache caches the results of all queries performed to find a set of rules to be triggered. The next time a trigger is performed in that JVM with the same rules specified, the rules will be found in the cache and the query will not actually require going to the server.

Once the rules are found in the cache they are triggered, either locally or remotely, depending on how they were defined. If a rule found in the cache is specified to be triggered locally, then the entire trigger process for that rule is performed on the client. No calls to the server are required. Even if the rule is specified to be triggered remotely, finding the rule in the cache eliminates one call to the server since the query does not have to be performed on the server.

The BRBeans cache can improve performance greatly, however it has one disadvantage: changes made to rules are not recognized immediately.

When a change is made to a rule on the server there is no way to inform all the potential clients that something has changed and that they therefore may need to refresh their caches. This effectively means that the client cache must check periodically to see if anything in the persistent rule data has changed. This is implemented by associating a polling frequency with the cache. This polling frequency specifies an interval of time that the cache will wait before checking to see if anything has changed. The next time a trigger is performed after a polling interval has passed, the cache will check to see if any changes at all have been made to the persistent rule data stored on the server. If no changes have been made, then the cache is not refreshed. If any changes at all have been made, the entire cache is cleared so that the changes will be picked up. Thus changes to the rules are only picked up by the cache after a polling interval has passed.

The default polling frequency is 10 minutes. The user can change this value by changing the single initialization parameter specified for the special rule named com/ibm/websphere/brb/BRB CacheRule. The value for this initialization parameter has the following format:

. Note that when this value is changed it will not take effect until the previous polling interval has passed. Thus, if the previous polling interval is set to 24 hours and the polling frequency is changed to 1 hour, the new frequency will not take effect until the previous 24 hour polling interval passes. The only other ways to get the new frequency to take effect are to restart the client (since this will cause the cache to be reinitialized from scratch) or to have the client code call the refreshCache method on the TriggerPoint object. If there is more than one client JVM performing triggers, this has to be done for each client since each JVM has its own cache. Note that there is only one BRB CacheRule and this rule applies to all clients. There is no way to set different polling frequencies for different clients.

Caching can be disabled for a particular TriggerPoint object using the disableCaching method. After disableCaching is called any triggers performed using that TriggerPoint object will not use the cache. Triggers performed using other TriggerPoint objects are not affected.

  Next topic