![]() |
|
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:
hh:mm:ss
.where hh stands for hours, mm stands for minutes, and ss stands for seconds.
Thus the default of 10 minutes
is specified by a value of 00:10:00
. To specify a polling frequency
of, for example, 1 hour, 30 minutes, specify 01:30:00
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.
Related concepts... | |
Parent: Improving performance - overview | |
Using servlets to improve performance | |
Using indexes to improve performance | |
Changing the firing location to improve performance | |
View PDF file... | |
To view a PDF file containing this article and related articles, click: | |
![]() | |
![]() |