I understand that logical insertions in Drools does not insert two facts that are equal according to their #equals implementation (and associated #hashCode logic). I'm basing this off of my own investigation plus the (well written) documentation @ http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/.... However, normal/stated fact assertions only use identity-based equality checks - by default. It looks like this can be changed to value-based equality via RuleBaseConfiguration. I have found some related, old Jiras: https://issues.jboss.org/browse/JBRULES-266 https://issues.jboss.org/browse/JBRULES-233 In both cases, Mark Proctor had a final remark, but I wasn't able to understand what was really decided and why. One specific comment @ https://issues.jboss.org/browse/JBRULES-266 is, "logical assertions are always equality based. Stated facts can now use identity and equality - using your configuration settings. I have added another configuration setting to dictate how logical over-ride works. Does it discard the original fact, or turn it into two stated fact handles." What is the reasoning behind only using the value-based equality for logical assertions? Why is it not configurable as stated fact assertions are? Also, why is the default behavior of stated fact assertion to be identity-based equality? - I find the inconsistency between the default for normal assertions and the (only option) for logical assertion to be a bit confusing/inconsistent. I'm just looking for an understanding the motivation behind these design decisions. I have had a lot of performance issues using, primarily, logical assertions due to the "no duplicate" checking being done. Even the stated assertions do still come with a cost of creating the initial FactHandle. With deeply nested/complex domain objects, the #equals and #hashCode implementations may be quite expensive when executed many times throughout rule execution. This is especially prominent in accumulators that may later accumulate these objects into collections that then are also subject to this equals/hashCode "penalty". I have a related post a while back @ http://drools.46999.n3.nabble.com/Object-size-impact-on-session-insertion.... I do not believe it is typical to use complex domain model objects as the keys to something like a HashMap. One reason (there are more; especially for mutable objects) would be due to the performance around having them be hashed and equality checked regularly when the map is accessed, modified, etc. The creation of many FactHandle's has shown up in some of my profiling performance problems due to this the constructor immediately hashing my domain model objects. I think the reason the fact handles use this information is for value-based equality comparisons - such as the only method used by the Truth Maintenance System logical assertions. I would really appreciate more insight into the motivation for not allowing #equals facts to be logically asserted separately into working memory - especially since there is a price to pay for the behavior in my case. -- View this message in context: http://drools.46999.n3.nabble.com/Equality-semantics-of-logical-assertion... Sent from the Drools: User forum mailing list archive at Nabble.com. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

On Jul 2, 2014, at 10:18 AM, "mikerod [via Drools]" <ml-node+s46999n4030228h25(a)n3.nabble.com&gt; wrote: Thanks a lot for the detailed response. This line of reasoning makes sense to me. I can see now why the behavior is the way that it is. I appreciate the quick feedback too! If you reply to this email, your message will be added to the discussion below: http://drools.46999.n3.nabble.com/Equality-semantics-of-logical-assertion... To unsubscribe from Equality semantics of logical assertions and stated assertions, click here. NAML

Hi, from what I see, the protobuf cache that the KnowledgeBuilder produce and saves as *.cache, is not currently used anywhere, right? If so, what would it be required to reload the compilation data inside the KnowledgeBuilder? There's something I'm missing or there is some piece of code demonstrating this capability? Best regards, Federico. _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Hi Edson, yes I saw that the JavaDialect class retrieve the compilation cache from the conf, but after a quick search it seems no one use the setCompilationCache method of KnowledgeBuilderConfigurationImpl, not even in the tests. So I was wondering what was the best way to use it... Maybe I get something wrong, in that case, I apologize :) Federico. On 07/07/2014 21:04, Edson Tirelli wrote: > Federico, > > Not sure why you say it is not used? > > Drools tries to use any pre-compiled resource bytecode if it is > available in the cache. If it is not available, it falls back to JIT > compilation: > > https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/main... > > Edson > > On Sat, Jul 5, 2014 at 11:34 AM, Federico Bertola > <federico.bertola88(a)gmail.com&gt; wrote: >> Hi, >> from what I see, the protobuf cache that the KnowledgeBuilder produce >> and saves as *.cache, is not currently used anywhere, right? If so, what >> would it be required to reload the compilation data inside the >> KnowledgeBuilder? There's something I'm missing or there is some piece >> of code demonstrating this capability? >> >> Best regards, >> Federico. >> _______________________________________________ >> 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