Most of the topics introduced so far in this chapter are not exclusive to the PHREAK algorithm. And this is not really a surprise; after all, the PHREAK algorithm is an evolution of the RETE algorithm implementation from previous versions of Drools (RETEOO). Even if both algorithms have a lot in common, PHREAK introduces some interesting modifications in the way the network of nodes is evaluated. Let's cover the most important improvements of PHREAK over RETEOO.
When the PHREAK engine is started, all the rules are said to be unlinked. An unlinked rule is never going to be evaluated by Drools. When the insert, update, and/or delete actions modify the state of a KIE Session, the modification is only propagated up to the alpha sub-network and queued before it enters the beta sub-network. Unlike RETEOO, in PHREAK no Beta Node is then evaluated as a consequence of any of these operations. A heuristic determines which rule is the most likely to result in a match and thus imposes an evaluation order between them.
Only when all the nodes of a rule have data to be evaluated is the rule considered to be linked. But the nodes of a rule are not evaluated as soon as they become linked; all linked rules are added into a queue that is ordered according to the salience of each rule. Different Agenda Groups have different queues and only rules from the queue of the active Agenda Group are evaluated.
From an API perspective, there is no difference between RETEOO and PHREAK. But internally, PHREAK will delay the evaluation of the beta sub-network until the fireAllRules() method is invoked, and not until the insert, update, or delete operations are invoked.
In RETEOO, every time a fact was inserted/updated/deleted, the network was traversed from the top (the Entry Point) to the bottom (the Rule Terminal Node in the best-case scenario). Each node that was evaluated in the network created a tuple that was propagated to the next node in the path. This behavior was the one we used throughout this chapter to explain the basics of PHREAK. But, in reality, PHREAK doesn't work that way. All the insert/update/delete operations that were queued for a Beta Node are batch-processed and their results added to a set. This set is then forwarded to the next node in the path where all the queued actions are again evaluated and added into the same set. This set-oriented propagation provides performance advantages for certain rules and it leaves the door open for future optimizations regarding multi-threading evaluation of a network.
The nodes that are shared among different rules in a KIE Base form segments. A rule is then seen by PHREAK as a path of segments rather than a path of nodes. A rule that doesn't share any of its nodes with any other rule is formed by a single segment. Each node inside a segment is assigned to a bit-mask offset. Each segment in a path is also assigned with a bit-mask offset. When a node contains enough data in its input to be evaluated, its bit is set to on. When all the nodes in a segment are on, the segment itself is set to on. A rule is then considered linked when all its segments are on. These bit-mask offsets are utilized by Drools to avoid the re-evaluation of already evaluated nodes and segments, providing more efficient evaluation of the PHREAK network.
Note
Drools 6.4 will introduce more interesting changes regarding how and when rules are evaluated in PHREAK. More information can be found in the following blog post: http://blog.athico.com/2015/12/drools-detailed-description-of-internal.html.
The goal of this section was to provide a simple and comprehensive list of the differences between RETEOO and PHREAK, but this list is by no means complete. For a better and deeper understanding of what PHREAK is and how it works, you are recommended to read Drools' documentation section for PHREAK: http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch05.html#PHREAK.