Thanks W. I understand your point about overusing salience -- I have read
not to rely on it, but find that I pretty often "need" to order my rules. I
seem to have two causes for this: a hierarchy of rules (a la, if then else);
and, a number of actions I want to execute before any business rules (like
adding a new SEvent object) and then again after the business rules (like
removing the large event). Any recommended reading on patterns that help
get away from using salience?
In my case, I have many events coming in that look the same. I am looking
for particular transitions on one property of the event (e.g., "when the
same flavor of event comes in, and the status property changes from "On" to
"Off" do something"). Additionally, I only want to execute my action on
the
transition from On to Off, once over a period of time (I use an object in
memory to keep track of when the last action was executed.) The reason I'm
explaining these details is that I think this means I need to keep the facts
in order (vs. just knowing which I have and have not evaluated for the
transition).
For my current solution, I created a simple java class that has a method
getCount():
public class XCounter {
static AtomicLong count = new AtomicLong(0);
public Long getCount() {
return count.incrementAndGet();
}
}
Then, I created a function (I'm using guvnor) called addOne that checks to
make sure the object above exists and creates it if it doesn't, and calls
getCount(). When I create the new small event SEvent, I set a new property
(xid) on the object with a call to getCount(). I compare xid's on the
SEvent rather than use the "after" capability. (Similar I think to your
suggestion I think but in the rules vs in the app inserting the events).
This seems to work keeping everything in order, BUT I am using persistence
(it is a long-running session) so I need to do some testing to see if the
object/value of XCounter is persisted with WM. Otherwise, obviously if the
system restarts the xid on any SEvents in memory will be out of order.
Do you have any thoughts about this implementation?
Thanks again,
-J
ps. Don't you think the drools temporal operators in stream mode should
work deterministically? In other words, drools should track the order in
which events were inserted so that the "after" always works - even if they
are inserted during the same ms)?
--
View this message in context:
http://drools.46999.n3.nabble.com/Fusion-5-5-Deterministically-identifyin...
Sent from the Drools: User forum mailing list archive at
Nabble.com.