[rules-users] The effect of not using shadow facts

[Chris West]

Is that still true if the equals() and hashcode() methods are only based on
the identity fields of the object (which cannot change)?

-Chris West

On 7/17/07, Mark Proctor <mproctor at codehaus.org> wrote:
>
>  you only need to use modifyRetract if the object is inserted. The reason
> for this is if you change field values on your facts we will not be able to
> remove them from our various internal hashmaps; thus the need to remove
> first prior to any changes, then make the changes and then insert it again.
> We can't allow users to just call update() as we have no idea what the old
> values where, thus we cannot find the objects in our hashmaps.
>
> Mark
> Chris West wrote:
>
> Mark,
>
> Using modifyRetract and modifyInsert seems to fix the problem (at least in
> my test case I finally created).  I'll try this on my real code.
>
> My only concern here is that it puts the burden on the rule author to know
> whether things are being shadowed or not.  For shadowing that is explicitly
> turned off this is ok.  But for implicit non-shadowing based on a class
> being final, this is not at all obvious to the rule auther.
>
> Is there any way to have this hidden such that I can still call "update"
> but have it use "modifyRetract" and "modifyInsert" instead?
>
> Also, I'm curious why I have to call modifyRetract before I start modifing
> the object, since the engine does not know about my modifications anyway
> until I call update or modifyInsert?  By the way, I was unable to use the
> block setter approach in the rule consequence due to not having set methods
> for modifying my objects.
>
> Thanks,
> -Chris West
>
> On 7/17/07, Mark Proctor <mproctor at codehaus.org> wrote:
> >
> > If you do not have shadow facts you cannot use the update() method, it
> > will leave the working memory corrupted. Instead you must manage this
> > yourself, before you change any values on the object you must call
> > modifyRetract() and after you hvae finished your changes ot hte object call
> > modifyInsert() - luckily if you are doing this in the consequence you can
> > use the MVEL modify keyword combined with the block setter and it does this
> > for you:
> > modify ( person ) { age += 1, location = "london" }
> >
> > Mark
> > Chris West wrote:
> >
> > Hello,
> >
> > With prior versions of JBoss Rules (3.0.5) I have been using JDK
> > generated dynamic proxies as facts, and they have been working fine.
> > However, after upgrading to JBoss Rules 4.0.0MR3, I cannot seem to get
> > the dynamic proxies to work as facts.  It seems that even though a rule
> > fires that changes a field on the proxy, a second rule that should not be
> > activated after the update still fires.
> >
> > According to the JDK javadoc documentation, dynamic proxies are created
> > as final.  My assumption is that JBoss Rules is not creating Shadow facts
> > for these since they are final.  After reading the JIRA at
> > http://jira.jboss.com/jira/browse/JBRULES-960, I now am questioning what
> > the effect of not using shadow facts is on the engine.  The relevant part of
> > that is:
> >
> > "The problem is that SpringAOP is generating a proxy whose methods
> > equals() and hashCode() are "final". As drools must either override these
> > methods in the shadow proxy or not shadow the fact at all, I'm disabling
> > shadow proxy generation for this use case.
> > It is really important to note that if you are asserting SpringAOP
> > proxies as facts into the working memory, you will not be able to change any
> > field value whose field is constrained in rules or you may incur in a memory
> > leak and non-deterministic behavior by the rules engine. Unfortunately there
> > is nothing we can do about, since when SpringAOP makes the methods equals
> > and hashcode final, we can't override them anymore and as so, we can't
> > shadow them."
> >   [ Show » <http://jira.jboss.com/jira/browse/JBRULES-960> ]
> >  Edson Tirelli<http://jira.jboss.com/jira/secure/ViewProfile.jspa?name=tirelli>
> > [02/Jul/07 03:29 PM] The problem is that SpringAOP is generating a proxy
> > whose methods equals() and hashCode() are "final". As drools must either
> > override these methods in the shadow proxy or not shadow the fact at all,
> > I'm disabling shadow proxy generation for this use case. It is really
> > important to note that if you are asserting SpringAOP proxies as facts into
> > the working memory, you will not be able to change any field value whose
> > field is constrained in rules or you may incur in a memory leak and
> > non-deterministic behavior by the rules engine. Unfortunately there is
> > nothing we can do about, since when SpringAOP makes the methods equals and
> > hashcode final, we can't override them anymore and as so, we can't shadow
> > them.
> >
> > Although I'm not using SpringAOP, I believe my facts are not being
> > shadowed.
> >
> > Is it true that not using shadow facts may lead to non-deterministic
> > behavior?  Prior to shadow facts, the engine seemed to handle it.  Any
> > chance of reverting back to the old style of truth maintenance in the case
> > of not using shadow facts.
> >
> > I apologize if I'm not on the right track here.  My only test case for
> > my problem is the entire application right now, so I cannot offer it for
> > discussion.  Any advice would be greatly appreciated.
> >
> > Thanks,
> > -Chris West
> >
> >  ------------------------------
> >
> > _______________________________________________
> > 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
> >
> >
> ------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.orghttps://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20070717/2c214e00/attachment.html