[rules-users] [Drools Planner] Hard constraint appears to be ignored - How to isolate a working memory corruption in drools expert

[Reinis]

Sorry to re-activate this thread, but I was thinking and discussing a lot on this topic (thanks Sotty and Geoffrey).
And I am still in doubt even after the explanation from Wolfgang. Until now I think there are more interpretations on how it might be instead of explicit explanation.

Of course the atomicity of fact modification is important thing, but what I am trying to understand is, why does this error occur in simple conditions (such as a testcase with domain model of two classes and very few attributes).
The testcase I previously built did not do anything else, there are no additional rules that would cause side effects, no additional facts in working memory, just four foos and two bars.

My argument is, that if late update cause retraction, reevaluation and what not, why is that this example works:

{code}
fooLeft.setBar(fooRight.getBar());
session.update(fooLeftFact, fooLeft);
fooRight.setBar(barLeft);
session.update(fooRightFact, fooRight);
{/code}

I find it weird that even though I did NOT refresh fooRight the error goes away. For me, such a fix would look feasible:

{code}
fooLeft.setBar(fooRight.getBar());
session.update(fooLeftFact, fooLeft);
fooRight = session.getObject(fooRight);<---- but I don't do this in real example, still it does not fail
fooRight.setBar(barLeft);
session.update(fooRightFact, fooRight);
{/code}

Second point is that I take that the session.update() is synchronous, so it should NOT matter if I do this

session.update(fooLeftFact, fooLeft);
fooRight.setBar(barLeft);
session.update(fooRightFact, fooRight);

or this

fooRight.setBar(barLeft);
session.update(fooLeftFact, fooLeft);
session.update(fooRightFact, fooRight);

the difference is just a few millis and i kinda cannot accept that the "correct" working memory state depend on such sort of things and that it is intended behavior.

kind regards
Reinis

On 03/10/2012 08:24 PM, Wolfgang Laun wrote:

> The Rete algorithm imposes severe restrictions on the way fact updates 
> may be performed and the when and where these changes are advertised 
> to the inference engine.
>
> The picture that's in my mind is one of many evaluations of boolean 
> expressions in parallel on many fact objects, partially being held up 
> due to lack of additional fact matches or true properties, and 
> partially waiting for being "fired"; and such evaluations are 
> "snapshot" as data structures in the Engine's memory. Due to an 
> announcement of a change in one fact such recorded evaluations may 
> have to be retracted and retraced, reevaluating conditions with their 
> unchanged partners. But some of that partner data may have been 
> represented in Engine memory, and this is what matters for the 
> reevaluation - not the actual content of that partner's object data.
>
> -W
>
>
> On 10 March 2012 19:38, Reinis <drools at orbit-x.de 
> <mailto:drools at orbit-x.de>> wrote:
>
>     Closing this thread!
>
>     Error was in this code-block:
>
>     {code}
>     fooLeft.setBar(fooRight.getBar());
>     fooRight.setBar(barLeft);
>     session.update(fooLeftFact, fooLeft);
>     session.update(fooRightFact, fooRight);
>     {code}
>
>     following fix makes the error go away:
>
>     {code}
>     fooLeft.setBar(fooRight.getBar());
>     session.update(fooLeftFact, fooLeft);
>     fooRight.setBar(barLeft);
>     session.update(fooRightFact, fooRight);
>     {code}
>
>     Pull request retracted and I have a bad taste in my mouth since I
>     have no technical/logical explanation why so.
>
>     Thank you guys for all the help!
>
>
>     On 03/09/2012 02:21 PM, Wolfgang Laun wrote:
>
>     > Works also with 5.4.0.Beta2.
>     >
>     > Does this really fail in the context of Drools' unit tests?
>     >
>     > -W
>     >
>     >
>     > On 9 March 2012 12:23, Wolfgang Laun <wolfgang.laun at gmail.com
>     <mailto:wolfgang.laun at gmail.com>
>     > <mailto:wolfgang.laun at gmail.com
>     <mailto:wolfgang.laun at gmail.com>>> wrote:
>     >
>     >     Can't reproduce the described effect with 5.3.0.Final, will
>     look at
>     >     5.4.0.Beta2 later today.
>     >
>     >     As far as I can see, the test case asserts the correct
>     result which
>     >     Drools produces anyway?
>     >
>     >     -W
>     >
>     >     On 09/03/2012, ge0ffrey <ge0ffrey.spam at gmail.com
>     <mailto:ge0ffrey.spam at gmail.com>
>     > <mailto:ge0ffrey.spam at gmail.com
>     <mailto:ge0ffrey.spam at gmail.com>>> wrote:
>     > > Great work Reinis!
>     > >
>     > > --
>     > > View this message in context:
>     > >
>     >
>     http://drools.46999.n3.nabble.com/rules-users-Drools-Planner-Hard-constraint-appears-to-be-ignored-tp3777209p3812319.html
>     > > Sent from the Drools: User forum mailing list archive at
>     Nabble.com.
>     > > _______________________________________________
>     > > rules-users mailing list
>     > > rules-users at lists.jboss.org
>     <mailto:rules-users at lists.jboss.org>
>     <mailto:rules-users at lists.jboss.org
>     <mailto:rules-users at lists.jboss.org>>
>     > > https://lists.jboss.org/mailman/listinfo/rules-users
>     > >
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > rules-users mailing list
>     > rules-users at lists.jboss.org <mailto:rules-users at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/rules-users
>
>     _______________________________________________
>     rules-users mailing list
>     rules-users at lists.jboss.org <mailto: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