Version 10

    Instance vs Set Execution Semantics

    Drools 5.x and earlier used tuple based matching and had instance oriented execution semantics. This means each rule activation and it's execution is independant from any other rule activation and fired sequentially.

     

    Drools 6.0 will utilise set oriented matching and thus be able to provide set execution semantics. This requires language enhancements to expose this capabiltiy to the user.

     

    Set Execution (please add additional related papers)


     

    Procedural Executions  (please add additional related papers)

     

    Annotations

     

    Annotations


    @Salience
    @Before
    @After
    
    @All
    @Direct
    @Async
    

     

    • @Direct
      • The match executes the moment it reaches the terminal node
        • No agenda
        • Typical for ECA rules
        • Cannot be used with @Salience, @Before and @After. If there is an instance it fires.
    • @All
      • All matches are executed as part of a set.
      • A container representing the set of matches is placed onto the Agenda.
        • The container obeys @Salience, @Before, @After
        • once it's popped all it's contents are evaluated as one operation.
    • @Async
      • The action, regardless of set or instance execution, is executed Asynchronously for long running tasks.

     

    Default Value

    No annotations are given, it assumes

    @Salience( 0 )
    

     

     

    Examples


    The Match instance is placed onto the agenda with a salience of 15, with normal execution behaviour

    @Salience( 15 )
    

     

     

    The Match iinstance s placed onto the agenda with a salience of 15, the execution will be done async in another thread (for long running actions)

    @Async
    @Salience( 15 )
    

     

     

    A set of all matches is placed onto the agenda, default salience of 0, once it's popped all matches in the set are executed as a single operation.

    @All
    

     

     

    A set of all matches is placed onto the agenda, salience of 15, once it's popped all matches in the set are executed as a single operation.

    @Salience( 15 ) 
    @All
    

     

     

    A set of all matches is placed onto the agenda, default salience of 0, once it's popped all matches in the set are executed as a single operation. Although each match is spun off into an async handler for execution.

    @Async
    @All
    

     

     

    Instance oriented activations that fire as soon as they reach the terminal node - ECA style rules. @Direct would probably need to have their beta network evaluated constantly, on say a 200ms interval, as they cannot be done lazily.

    @Direct
    

     

    Same as above, but the actions are executed async.

    @ASync
    @Direct
    

     

    Example:

    // Evaluate and Execute valid1 as a set
    @Validation
    @All
    rule valid1 when
       … LHS …
    then
       … RHS ...
    end
    
    // Evaluate and Execute valid1 as a set
    @Validation
    @All
    rule valid2 when
       … LHS …
    then
       … RHS ...
    end
    
    
    // Evaluate and Execute valid1 as a set, after all @Validation rules have been executed
    @Calculation
    @All
    @After( @Validation )
    rule calc1 when {
       … LHS …
    } then {
       … RHS ...
    }
    

     

     

    Additional Thoughts

    Set Boundaries and Cleanup

    For procedural rules this is very clear. Only the trigger goal fact is reactive the building of the set and execution of the actions are passive and the trigger fact is cleared up after the set is evaluated. With @All what are the set boundaries if the trigger goal is not removed, as it will continue to received matches for the rest of the rule. How do we clean up the trigger/goal?

     

    One option is to expose the life cycles as listeners to which code can be attached, cleanup code can executed there:

    @Calculation
    @All
    @After( @Validation )
    rule calc1 when
        $g : Goal()
       … LHS …
    } then {
       … RHS ...
    } onAfterAllFire {
        retract( $g )
    }
    

     

    Other proposed life cycles:

    • OnBeforeMatchFire
      • Before a single Match instance is executed
    • OnAfterMatchFire
      • After a single Match instance is executed
    • onBeforeAllFire
      • Before any Matches in the set have fired
    • onAfterAllFire
      • After all Matches in the set have fired
    • onDeleteMatch
      • invoked when a Match is deleted (no longer true)
    • onUpdateMatch
      • invoked when a Match is updated
    • onChangeMatch
      • invoked when a Match is either updated or deleted