The automatic memory management for events is only performed when running the engine in STREAM mode. Check the Event Processing Mode section for details on how the STREAM mode works.
One of the benefits of running the engine in STREAM mode is that the engine can detect when an event can no longer match any rule due to its temporal constraints. When that happens, the engine can safely retract the event from the session without side effects and release any resources used by that event.
There are basically 2 ways for the engine to calculate the matching window for a given event:
explicitly, using the expiration policy
implicitly, analyzing the temporal constraints on events
The first way of allowing the engine to calculate the window of interest for a given event type is by explicitly setting it. To do that, just use the declare statement and define an expiration for the fact type:
Example 2.18. explicitly defining an expiration offset of 30 minutes for StockTick events
declare StockTick @expires( 30m ) end
The above example declares an expiration offset of 30 minutes
for StockTick events. After that time, assuming no rule still needs the
event, the engine will expire and remove the event from the session
automatically.
Another way for the engine to calculate the expiration offset for a given event is implicitly, by analyzing the temporal constraints in the rules. For instance, given the following rule:
Example 2.19. example rule with temporal constraints
rule "correlate orders" when $bo : BuyOrderEvent( $id : id ) $ae : AckEvent( id == $id, this after[0,10s] $bo ) then // do something end
Analyzing the above rule, the engine automatically calculates
that whenever a BuyOrderEvent matches, it needs to store it for up to 10
seconds to wait for matching AckEvent's. So, the implicit expiration offset
for BuyOrderEvent will be 10 seconds. AckEvent, on the other hand, can only
match existing BuyOrderEvent's, and so its expiration offset will be zero
seconds.
The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two.