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

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(a)codehaus.org&gt; 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(a)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=tirell... > > [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(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > > > _______________________________________________ > > rules-users mailing list > > rules-users(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > ------------------------------ > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users