Just like with Object Type Nodes, Alpha Nodes can be shared among multiple rules (or patterns inside a rule) in a knowledge base. If the same constraint is used in more than one pattern, Drools will optimize the creation of the PHREAK network and a single Alpha Node will be used.

Let's assume the following two rules:

rule "Sample Rule 1"
when
    $c: Customer(age > 30, category == Category.GOLD)
then
    channels["gold-customer-channel"].send($c);
end

rule "Sample Rule 2"
when
    $c: Customer(age > 30, category == Category.SILVER)
then
    channels["silver-customer-channel"].send($c);
end

The earlier two rules have the same condition (age > 30) duplicated. The corresponding PHREAK network for these two rules will look like the following one:

As we can see, the Alpha Node that corresponds to the duplicated constraint only appears once in the network. In addition to saving some memory, Alpha Node sharing reduces the evaluation time of a knowledge base because a condition that is present in multiple rules needs to be evaluated just once.

We have already mentioned that the order of the constraints in a pattern dictates the order of the corresponding Alpha Node in the PHREAK network. This concept is particularly important regarding Alpha Node sharing. For an Alpha Node to be shared, the order of the constraint must be the same in all the patterns. For example, the following two rules are semantically identical to the two rules introduced before, but the order of the constraints in the pattern in the second rule was altered:

rule "Sample Rule 1"
when
    $c: Customer(age > 30, category == Category.GOLD)
then
    channels["gold-customer-channel"].send($c);
end

rule "Sample Rule 2"
when
    $c: Customer(category == Category.SILVER, age > 30)
then
    channels["silver-customer-channel"].send($c);
end

If we analyze the PHREAK network generated by the new version of our rules, we will notice something interesting:

Because the order of the age constraint is not the same in the two rules, the corresponding PHREAK network will contain a duplicated alpha node. The major drawback here is that certain facts (for example, a SILVER Customer) will trigger the same evaluation over the same logical constraint multiple times.

In order to evaluate the constraints of the rules in a knowledge base, Drools heavily relies on MVEL. MVEL, by default, uses an interpreter to evaluate the constraint expressions. This means that, most of the time, the evaluation of a constraint is not really happening at the Java bytecode level, which means that it is not as efficient as it could be.

Fortunately, Drools provides a way to compile an MVEL expression into Java bytecode. Because this compilation happens in runtime, it is usually referred as JIT (just-in-time) compilation. But of course, there is a catch. Otherwise, why does Drools not simply compile to bytecode all the constraints in a knowledge base? One of the major drawbacks of JIT compilation is that it could be memory-intensive and may create problems related to the permanent generation heap.

The way Drools deals with this drawback in JIT compilation is by using a threshold on the number of times a constraint is evaluated before it is compiled into bytecode. The assumption here is that, if a constraint is never evaluated, or is only evaluated a couple of times, it is more efficient to evaluate it in interpreted mode than to JIT-compile it. In Drools 6.3 the default threshold is 20 times.

There are two common ways in Drools to tune the default JIT threshold according to the specific needs of an application:

The entire JIT compilation can be disabled by setting a negative threshold value.

It shouldn't come as a surprise at this point that Beta Nodes can also be shared among multiple rules in the PHREAK network. As an example, let's see how Drools models the PHREAK network for the following two rules:

rule "Sample Rule 1"
when
    $p:  Provider(rating > 50)
    $pr: ProviderRequest()
then
    channels["provider-channel"].send($pr);
end

rule "Sample Rule 2"
when
    $p:  Provider(rating > 50)
    $pr: ProviderRequest()
    $o:  Order()
then
    channels["order-channel"].send($o);
end

The first two patterns in the preceding rules are identical. We already know that the Alpha Node belonging to the constraint on the first pattern will be shared among the rules. What we didn't know yet was that the Beta Node for the join between the Provider and ProviderRequest patterns will also be shared:

As we can see, the Beta Node at the top is shared among both rules.

It is important to note that, in order for a Beta Node to be shared, the order of the patterns in the rules matters. The concept is similar to the order of the constraints in a pattern when we were talking about Alpha Node sharing: if the order is not the same, Drools will not optimize it. For example, if we modify the second rule in our example by inverting the order of the first two patterns, the semantics of the rule doesn't change, but its underlying implementation in PHREAK does:

rule "Sample Rule 2"
when
    $pr: ProviderRequest()
    $p:  Provider(rating > 50)
    $o:  Order()
then
    channels["order-channel"].send($o);
end

The resulting PHREAK network in this case will look like the following:

Because the order of the first two patterns in our rules is no longer the same, a new Beta Node now appears in the corresponding PHREAK network. But the order of the patterns is not the only thing that matters when it comes to Beta Node sharing: the nodes previous to a shared Beta Node must also be the same in order for Drools to optimize it. As an example, let's go back to our original rules, but let's change the rating constraint of the Provider in the second rule to 60:

rule "Sample Rule 2"
when
    $p:  Provider(rating > 60)
    $pr: ProviderRequest()
    $o:  Order()
then
    channels["order-channel"].send($o);
end

What we have basically done is to break the shared Alpha Node both rules had. This means that our Beta Nodes for the first two patterns have different inputs now:

The preceding network now shows two different Alpha Nodes that result in two different Beta Nodes.

As we can see, Beta Node sharing is not particularly easy to achieve; when designing our rules, we must always try to keep the same order between patterns and constraints inside the patterns when they are reused among multiple rules. DSL, Templates, and Decision Tables are all good alternatives to ensure that this order is kept for large knowledge bases.

A curious thing happens in the PHREAK network when the or conditional element is used between patterns. As a matter of fact, Drools doesn't really understand the or conditional element at all; what it does is to convert it into a semantically equivalent set of sub-rules inside the PHREAK network.

As an example, let's assume we have a rule to detect when a Customer that is not GOLD has a SuspiciousOperation or an Order bigger than $100,000. This rule can be written as follows:

rule "Sample Rule 1"
when
    $c: Customer(category != Category.GOLD)
    (
        Order(customer == $c, total > 10000) or
        SuspiciousOperation(customer == $c)
    )
then
    channels["suspicious-customer"].send($c);
end

Ideally, we should have used the conditional element exists to make sure we don't have multiple activations of this rule when multiple Orders or SuspiciousOperations for a customer exist. But, given that we haven't yet introduced the exists conditional element in this chapter, we will not use it.

The preceding rule will be converted by Drools into the following PHREAK network:

The network above shows the two sub-rules generated by Drools, evidenced by the presence of a duplicated Rule Terminal Node for the single rule we had. What Drools has basically done is to split the original rule into the following two rules:

rule "Sample Rule 1.1"
when
    $c: Customer(category != Category.GOLD)
    Order(customer == $c, total > 10000)
then
    channels["suspicious-customer"].send($c);
end

rule "Sample Rule 1.2"
when
    $c: Customer(category != Category.GOLD)
    SuspiciousOperation(customer == $c)
then
    channels["suspicious-customer"].send($c);
end

Each sub-rule in the PHREAK network is now independent: both of them can be independently activated and fired. This explains why there is no such thing as a short-circuit between patterns in Drools.