I am wondering if I might be affected by this problem as well since all my facts will be definstances and some of them will be dynamic. I thougt Jess was using hascode to handle a unique instance of the Java object as a fact and by default hascode was returning a code different for each object but immutable (for example the address of the object). But somehow from this thread it looks like Jess is using properties to identify unicity? Or is it my misunderstanding? Obviously, in a dynamic object, properties will change! And I really don't want several copies of facts of the same object in memory (representing in a way the history of the object), because this would have side effects with: - memory consumption - how to make sure an undefinstance will remove them all
Alexander On 7.10.2002 19:55, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > > The easiest thing might be for me to have a look at the Bean class, > and see if I can see a problem. If you don't want to share it with the > list you can send it to me privately at [EMAIL PROTECTED] . > > A future release of Jess is going to have to deal with this kind of > issue. I've been thinking that maybe you could specify to Jess that > certain properties are subject to spontaneous change and therefore > shouldn't beused in indices. Furthermore, the hashCode()s of > user-supplied Bean objects often don't behave the way they should, and > a way that Jess could avoid the problem is by managing objects using > Handles rather than directly --i.e., you wouldn't be allowed to say > "undefinstance(x)." When you called definstance(x) you'd get back a > return value y, and you could then say undefinstance(y). This is, I > think, a small price to pay. It forces the user to manage the possibly > changing objects, rather than having Jess do it. > > Of course, you can also use BeanInfo objects, something else we > mentioned on this list recently. A BeanInfo can specify that only > certain methods should be considered as properties, and others should > be ignored; you could ignore the troublesome property this way. > > I think Tim Good wrote: >> We are getting duplicate facts in our fact-base. The same >> fact-id appears twice when we run (facts) and is output >> twice in a (save-facts). Specific rules to examine the >> facts; however, only see the fact once. One of each pair can >> be retracted, but attempts to retract the remaining one fail >> with no message. >> >> The facts are dynamic definstances of java objects. The >> definstance and modification are done in a separate thread >> from the rules execution. No specific hashcode or equals >> method has been defined. >> >> The problem seems to be centered around modification of a >> specific bean property which has given us problems in the past. >> An earlier question (6/20) on a related issue got us this >> response. >> >> Furthermore, be sure that the hashCodes of the Beans, and of the >> objects they contain in their slots, do not change except as reported >> in a property change event. A common problem is having a container >> like a Set, Map or List as a Bean property. If data is added to the >> Set, Map, or List, its hashCode will likely change. Since the hashCode >> may have been used by Jess to organize facts in the Rete network, such >> a change will corrupt Jess's data structures, and so from that point >> on anything can happen. Bean properties should be simple value objects >> like Strings and Integers. >> >> >> The property is stored as a Map but passed as an array in its get >> method and propertychange event. The set method is not implemented. We >> thought it was taken care of at the time since it seemed to work but >> recent code changes have brought it back. >> >> I am not sure what questions to ask at this point. It seems that our use >> of the Map may be causing our problems. Can we use the map as a bean >> property at all? Do we have to define our own hashcode and equals >> method for the bean? How does Jess use the slot hashcodes? >> >> - Tim Good >> > > > > > --------------------------------------------------------- > Ernest Friedman-Hill > Distributed Systems Research Phone: (925) 294-2154 > Sandia National Labs FAX: (925) 294-2234 > Org. 8920, MS 9012 [EMAIL PROTECTED] > PO Box 969 http://herzberg.ca.sandia.gov > Livermore, CA 94550 > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- > -- Alexander Lamb Groupe Serveurs Applicatifs Division d'Informatique Midicale Htpitaux Universitaires de Genhve 21 rue Micheli-du-Crest CH-1211 Genhve 4 / Switzerland Tel: +41-22 372.48.46 Fax: +41-22 382.86.80 [EMAIL PROTECTED] / http://www.hcuge.ch -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
