It can also be used in a montoring sitation or as a continually running
web service, so drools can react to the environemnt - withing impacting
the environment by block threads.
Its just a fact assertion queue.
Peter Lin wrote:
Async asserts are typically used in real-time situations where there is a
constant stream of input from multiple threads. An example might be trading
application that does transaction routing or an OMS.
In those cases, it should fire activation as it occurs. In JESS, it's called
reactive mode. Within a single threaded use case, there's no point doing
async assert.
that's my bias 2 cents
peter
On 3/29/06, Geoffrey Wiseman <[EMAIL PROTECTED]> wrote:
On 3/29/06, Mark Proctor <[EMAIL PROTECTED]> wrote:
There might also be some settings to do with 2 phase commit, in that
when do we call fireAllRules? Do we call it after every assertion, after
a set time period, after X facts are asserted - or maybe a combination
of both? Initially probably esiest to just call fireAllRules on each
assertion from the Queue.
Interesting; perhaps I don't understand the intent.
Based on the brief description, seems like it's just a way to get facts in
without having to wait for that to happen. I would have thought you'd
simply let the api consumer fire all rules as per usual, but block on
pending assertions, possibly allowing an asynchronous fireAllRules call as
well, with some way to verify when the firing is complete.
But if you're going to fire all rules with each assertion, or on a time
period or after X facts asserted, you lose more control over the
lifecycle,
which makes me wonder how people would use the asynch assert.
- Geoffrey
--
Geoffrey Wiseman
