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.tire...@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.tav...@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.deja...@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@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/rules-users >> > >> >> _______________________________________________ >> rules-users mailing list >> rules-users@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
