Re: [rules-dev] Lazily Enabled Truth Maintenace (Project Propsoal)

if you look at the AbstractWorkingMemory insert method you'll see one > argument is whether it's a logical insertion or not. You'll also see it > check the global maintainTMS configuration and also retrieve the > ObjectTypeConf. So between those things someone should be able to get it > working. > Today, it enters a block where it operates on the equality map and also creates a default handle based on that TMS global option and *regardless* of whether it's a logical insert. If I'm *not* putting things in the equality map for regular inserts, when a logical insert comes in, but there were already stated inserts, how will I know that? I would create a new handle for the logical insert and do the tms.addLogicalDependency(...), even tough there were regular inserts before and this seems to be a wrong behaviour. Apparently, today, you can disable TMS and still use logical inserts in your drl, what, I believe, will lead to inconsistent behaviour, but you're at your own risk. Ideas? I feel that I missed something :) Cheers, Leo. P.S.: I reached the conclusions above based on the fact that LogicalAssertionTest started failing after I did the changes you suggested. On Wed, Sep 15, 2010 at 3:47 PM, Mark Proctor <mproctor(a)codehaus.org&gt;wrote: > On 15/09/2010 14:35, Michael Anstis wrote: > > Is this in drools-core; or drools-compiler? > > Whilst not undertaking to do the work; have a purpose to nose through > the code makes understanding easier. > > It's all in DroolsCore. > > It's a 5 minute hack for me and then 15 minute unit writing test. But I > thought I'd write it up in a hope to bring someone else into the fold, we > need more help writting the core engine someone else out there must want to > work on current edge engine design :) > > if you look at the AbstractWorkingMemory insert method you'll see one > argument is whether it's a logical insertion or not. You'll also see it > check the global maintainTMS configuration and also retrieve the > ObjectTypeConf. So between those things someone should be able to get it > working. > > Mark > > > On 14 September 2010 16:47, Mark Proctor <mproctor(a)codehaus.org&gt; wrote: > >> Here is another project proposal, this time simpler. I think this one >> has Wolfgang's name on it ;) >> >> http://blog.athico.com/2010/09/lazily-enabled-truth-maintenace.html >> >> Three weeks ago I posted the project idea for "Left and Right Unlinking"<http://blog.athico.com/2010/08/left-and-right-unlinkin...;. >> So far there are no takers, so if you are interested let me know :) >> >> In the meantime I tried to think of a simpler enhancement that we would >> like to see done. >> >> At the moment Drools has a user setting "MaintainTMSOption" which can be >> true or false. It's a small optimisation that when turned off avoids using >> the equality hashmap that is maintained for all inserted objects. >> >> It would be a much better idea to remove this configuration setting, thus >> simplifying things for end users and have TMS lazily enabled on demand. >> >> For each object type there is an "ObjectTypeConf" configuration object >> that is retrieved every time a working memory action, such as insert, is >> executed. The enabledTMS boolean should be moved there, so there is one per >> object type, by default it is false. >> >> When a working memory action occurs, like insert, it retrieved the >> ObjectTypeConf and checks the maintainTms boolean there, instead of the >> current engine scoped configuration. When a logical insertion occurs and the >> ObjectTypeConf is retrieved if maintainTms is false it sets the value to >> true and then iterates the associated ObjectTypeNode memory lazily adding >> all the objects to the TMS equality map. From then on for that ObjectType >> all inserted objects are added to that equality map. >> >> With this you now have the advantage of TMS being laziy enabled, so the >> minor hashmap operation is no longer used and likewise a small memory saving >> from not populating the map. There is a further advantage that this is now >> fine grained and when enabled only impacts for that specific object type. >> >> A further enhancement could use a int counter, instead of a boolean. Each >> logical insertion for that object type increases the counter, each >> retraction decreases the counter; even if automatically retracted if the >> truth is broken for that logical assertion. When the counter reaches zero, >> TMS for that OTN can be disabled. We do not however remove the objects from >> the equality map, as this would cause "churn" if TMS is continuously enabled >> and disabled. Instead when TMS is disabled record the current fact counter >> id. Then if TMS is disabled on a retraction but there is a counter id, we >> can check that counter id to see if the fact is prior to TMS being disabled >> and thus would need to be retracted from the equality map. >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > > _______________________________________________ > rules-dev mailing listrules-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > >