[Enterprise Extensions only]
  Previous topic

Changing the firing location to improve performance

The BRBeans framework allows you to specify where a particular rule should be fired. This determines where the rule implementor for the rule is actually instantiated and invoked. There are three possible values for the firing location:

  1. Local: Fires the Java rule implementor local to the client that fired the rule. This means in the same JVM in which the trigger was performed.

  2. Remote: Fires the Java rule implementor on the server where the rules exist.

  3. Anywhere: First tries to fire the Java rule implementor locally. If the Java rule implementor cannot be found, then it fires the Java rule implementor remotely. This is the default value.

For simple rule implementors that do not perform any server-intensive work, specifying local usually results in the best performance. This is true both with and without caching.

Without caching, the work done to fire a rule remotely involves the following:

  1. finding the rule
  2. determining whether the rule is to be fired locally or remotely
  3. calling fire on the remote rule
Each of these three operations requires a remote call to the server.

With caching the work done to fire a rule locally involves the following:

  1. finding the rule
  2. determining whether the rule is to be fired locally or remotely
  3. calling fire on a local copy of the rule
This requires only two remote calls.

With caching, local firing results in even more dramatic improvements since, if the rule is found in the cache, the entire rule firing process takes place locally with no remote calls. In fact, to get the full benefit of the cache, rules should be fired locally, (although remotely fired rules still benefit from the cache due to the elimination of the query on the server).

There may be some cases where a rule implementor must perform some work that requires much interaction with the server. In these cases it may actually be beneficial to have rules using this rule implementor defined to be fired remotely. This should make the server interaction performed by the implementor more efficient.

Note that, in addition to performance, maintenance must also be considered in relation to specifying a firing location. The rule implementor classes for rules that are defined to be fired locally must be present on any client system that tries to fire those rules. Otherwise the implementor cannot be instantiated when the rule is fired. This can result in maintenance problems when the rule implementors are changed since they must be updated on many different systems.

  Previous topic