Improving the performance of the sequential execution mode

To use the sequential algorithm, make sure that your rules are homogeneous and that the rules are not chained. In the sequential algorithm, you can define the number of rules to run per tuple and the order of execution by using control properties.

Sequential algorithm

To guarantee the same execution with either algorithm, both the following conditions are required:

  • The rules must be homogeneous. Homogeneous rules mean that the conditions of these rules must be set on the same kind and number of objects. If you try to apply the sequential algorithm to heterogeneous rules, it typically creates more tuple objects, which can result in more rules being run than in the RetePlus mode. The common tuple signature can also cause heterogeneous rules not to fire: When there are no corresponding instances in working memory, no tuples can be created.

  • The rules must not be chained, that is, the modification done in the action part of a rule must not lead to execution of another rule.

If you specify the sequential execution mode for rules that are not compliant with it, the engine raises an error.

The use of sequential execution mode is described further in the sections:

Tuples

A tuple is a list of objects that complies with a particular structure. A tuple structure is simply a sequence of class descriptors. Each location in a tuple structure is called a slot. The same class descriptor can appear more than once at different slots.

Take a tuple structure:

(Customer,Product)

Here is a tuple that complies with this structure:

(new Customer("Henry"),new DVD("Mickey"))

Note that the subclassing is taken into account because a DVD is a Product. However, some tuples that do not comply with the structure:

For example, the following tuple is too large:


(new Customer("Henry"),new CD("Madona"),new DVD("Mickey"))

This tuple is not correctly ordered:


(new DVD("Lord of the rings"),new Customer("Henry"))

And this tuple is too small:


(new Customer("Henry"))

In Java™, a tuple is easily implemented as an array of objects:


Java Tuple = Object[]

The Java code to create a tuple and its objects is:


new Object[] {new Customer("Henry"),new DVD("Mickey")}

At run time, the tuples are built automatically from the content of the working memory and then passed to the rule engine. The tuples are passed one after the other to the tuple-matching method.

Control properties in sequential mode

Control properties affect the sequential mode execution and the tuple structure. See Control properties for rule tasks in execution modes for more general information.

The number of rules to be executed per tuple and the order in which they execute can be specified with control properties: ordering, firing, and firinglimit.

The ordering property

The ordering property is mandatory for sequential processing. It describes the order by which the rules of the rule task will be executed.

There are two values available:

  • literal: The rules are kept in the order in which they are set into the task body (using up/down arrows).

  • sorted: The rules are sorted according to their static priorities.

Note that another value, dynamic, is available only for rule tasks using the RetePlus execution mode.

The firing property

The firing property specifies whether, for each tuple, all the rules or only the first rule that applies should be executed. This property is optional.

It has two possible values:

  • allrules

    This value means that all the rules that apply should be executed before skipping to the next tuple. This is the default value.

  • rule

    This value means that only the first rule that applies should be executed on the first tuple.

The firinglimit property

The firinglimit property gives another level of control when the firing property is set to allrules. It is used to specify a number that represents the maximum number of rules to be executed before skipping to the next tuple. This number should be greater than zero.

Known limitations of the sequential algorithm

The following table outlines the limitations of sequential processing, in particular its use combined with certain ILOG® Rule Language (IRL) constructs.

Limitation Description
ILOG Rule Language (IRL) limitations

Not all the rule patterns that have been designed for the stateful Rete matching are available. Compile time errors occur when a rule is not compliant with the current tuple-matching implementation.

Therefore, when sequential processing is used, the IRL does not support the following features:

  • dynamic priorities

    Because there is no agenda in sequential processing, only the rules with static priorities are allowed.

  • not, exists, collect conditions without an enumerator

    The not, exists, and collect conditions with an enumerator (from or in) are translated to Java bytecode. When an enumerator is specified, the set of objects is available as a value tied to the condition. (Note that this is not a limitation for RetePlus or Fastpath.)
Condition constructs

The following condition constructs are available in sequential processing:

  • simple condition—bindings and tests are available

  • from

  • in

Refraction

The data unit for an engine cycle is the tuple. The engine does not record the tuples as they are matched, it rather forgets them between cycles. Therefore, there is no built-in support for refraction.

Using the sequential execution mode, the above rule task becomes:

ruletask main {
   algorithm = sequential;
   ordering = literal;
   body = {Person,PersonProduct}
}

The execution trace shows that, by using the sequential execution mode, the same rule are run twice for the same parts of two different tuples.

Although there is no built-in support for refraction, the sequential execution mode uses a particular rule application strategy when it generates the body of the tuple matching method. The strategy, however, tries to limit the use of refraction.
ILOG Rule Language (IRL) facilities

In contrast, practically all the script-level expressions and statements of the IRL are available in sequential processing. They serve principally to maintain the consistency of the other rule tasks that are not set to the sequential algorithm.

Here is a list of these features:

Functions

Function definitions and calls are fully available.

Script-level expressions

All the IRL expressions are available. (Note that ?instance works in any execution mode.)

Script-level statements

All the IRL statements are available.

Update

The update construct is available because spurious updates might exist in rule tasks set to the sequential algorithm. A spurious update is an update on an object that cannot be matched by any condition part of rule tasks set to the sequential algorithm, but might be significant for other rule tasks using the RetePlus algorithm. All rule tasks are specified in the ruleset and should be kept consistent with the current engine. However, it is important to note that the usual update is not handled at all by the stateless sequential processing algorithm.

Repeatable rules

The repeatable rules are not handled by the sequential processing algorithm, but they might be relevant for other rule tasks that use the RetePlus algorithm.

Insert

Insertion of objects that could match condition parts of rule tasks set to the sequential algorithm might cause inconsistencies when the tuples of objects are extracted from working memory. This is because the objects are inserted in the first position, and the iterator building the tuples are not notified. The iterator does not, therefore, give the tuples involving the new object to the sequential processing engine. However, the insert is still relevant for other rule tasks using the RetePlus algorithm.