[rules-users] Inferencing

[Wolfgang Laun]

Delayed modifications of the facts database are bound to have an
impact on the semantics of your rule set (unless, perhaps, you are
writing them anticipating this execution cycle). A stateful session
effects changes immediately, which, in turn, affects the facts and the
agenda immediately. Delaying these changes for the next stateless run
will make rules fire in the current run, which would not do so in the
stateful execution scenario.

As for the initial question, whether there are real applications that
need stateful session, I'd like to say that there is a set of
applications that need stateful reasoning to be built according to the
(as I call it) Plant Design Pattern. Such an application is meant to
monitor a set of real world objects, with their dynamically changing
states as facts, and while observing incoming state changes and
operator commands. And, the important point is, that firing rule will
cause interaction with the real word.

-W


On Mon, Mar 8, 2010 at 6:21 PM, Pavel Tavoda <pavel.tavoda at gmail.com> wrote:
> Yes you are right but that should be a hidden detail like asynchronous
> connect is internally synchronous because you are waiting for
> confirmation packet (but not response) ;-).
>
> No way to implement execution without changing "global" state - am I
> right? BTW I implemented for one small subproject (IRC bot) mechanism
> where I listen to all new memory inserts and repeat them at beginning
> of next stateless session with new KnowledgeBase. Very simple and
> straightforward just 20 lines of code because I don't have to
> serialize it just keep in memory for next run.
>
> Pavel
>
> 2010/3/8 Edson Tirelli <ed.tirelli at gmail.com>:
>>
>>     Interesting analogy, but careful here:
>>
>> "Statefull is just series of stateless session where you transfer state from
>> one session to another."
>>
>>     Not sure what lead you to think that way, but it is actually the
>> opposite, and trying to explain that will make things REALLY confusing for
>> some. So, I would recommend anyone not interested in knowing internal
>> details to **stop reading here**!
>>
>>     Ok, if you are still reading, then I will try to explain in the simplest
>> way I can: "there is no such thing as stateless session in Drools
>> internals". Deep in drools internals, there is only stateful working memory,
>> that is exposed to the user in 2 different ways: a properly stateful
>> session, that allows users to manage the state, and a helper object that we
>> call "staless session". This helper staless session object, among other
>> things, simply holds a reference to the kbase and when the execute(...)
>> method is called, internally it creates a stateful session, inserts the
>> facts, fire the rules and disposes the session automatically. There are a
>> bunch of other helper mechanisms there, but the essence is just that:
>> simplify the use of stateful sessions for stateless scenarios.
>>
>>     Edson
>>
>> 2010/3/8 Pavel Tavoda <pavel.tavoda at gmail.com>
>>>
>>> It's like synchronous vs. asynchronous communication. In reality it's
>>> always asynchronous but from top view it appear synchronous.
>>> Similar to stateless vs. statefull. Statefull is just series of
>>> stateless session where you transfer state from one session to
>>> another. Look for Drools statefull persistency. In reality it is
>>> series of stateless sessions where you store status from one session
>>> result and use it as start for another session plus some new changes.
>>> This is my point of view of difference between stateless/statefull
>>> session specially how Drools make it.
>>>
>>> Regards
>>>
>>> Pavel
>>>
>>> On Mon, Mar 8, 2010 at 4:23 PM, Tim de Jager <tim.dejager at student.hu.nl>
>>> wrote:
>>> >
>>> > Hi everybody,
>>> >
>>> > I'm currently doing my bachelor thesis on Rule engines. This includes
>>> > comapring different Rule engine products. I have set up a small Java
>>> > program
>>> > (Conway's game of life) and I'm writing the 'engine' in different Rule
>>> > engines, while keeping the same GUI,CellGrid etc. I have already made a
>>> > Drools based engine.
>>> >
>>> > I have been studying the Rule engine subject for somewhat more then a
>>> > month
>>> > now. And I'm currently seeing two different developments namely the use
>>> > of
>>> > an inference engine and the generation of embedded code instead (Take,
>>> > Visual Rules etc.)  I can see some of the pro's and cons with both
>>> > paradigms. But I'm wondering what opinion some of you guys have on the
>>> > subject.
>>> >
>>> > I can see that without inferencing  it is very hard (or even impossible)
>>> > to
>>> > keep a statefull session inside the rule engine, haven't seen a
>>> > non-inferencing rule engine which does offer this possibility. And also
>>> > lose
>>> > features like TMS. But what would be a concrete example where a
>>> > statefull
>>> > session is absolutely necessary? Instead of letting the engine reason
>>> > over
>>> > all the facts in stateless way. And managing conflicts with a ruleflow
>>> > (see
>>> > Visual Rules for a nice example).
>>> >
>>> > I'm looking forward to hearing your thoughts.
>>> >
>>> > Thanks,
>>> >
>>> > Tim
>>> >
>>> > P.S I already read two of Mark Proctors blogs on inferencing, but while
>>> > enlightening, they didn't supply me with a definitive awnser
>>> > --
>>> > View this message in context:
>>> > http://n3.nabble.com/Inferencing-tp435411p435411.html
>>> > Sent from the Drools - User mailing list archive at Nabble.com.
>>> > _______________________________________________
>>> > rules-users mailing list
>>> > rules-users at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/rules-users
>>> >
>>>
>>> _______________________________________________
>>> rules-users mailing list
>>> rules-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>>
>> --
>>  Edson Tirelli
>>  JBoss Drools Core Development
>>  JBoss by Red Hat @ www.jboss.com
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>