Ernest, I would also like to weight in on this issue...
In my previous job we were synchronizing objects across a distributed system, where Jess was one component, using the PropertyChangeListener pattern to start the synchronization. When I looked at Jess and the JavaBean interaction I was surprised to find the slot by slot changes, and would have liked a collection of slots in a single transaction. In my current job, we are working with a high speed transaction processing system with million+ facts in memory. Performance is an issue, and from my initial measurements, the slot by slot change from Rete.modify is slower than a retract, Fact.setSlotValue, assert. I would vote for keeping the 6.1 behavior from the modify command, exposing the internal modify to Rete and Java, and doing a collection of slots for the change notification. Thanks, Jon Weygandt -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 08, 2005 8:36 PM To: jess-users@sandia.gov Subject: Re: JESS: Behavior change from 6.1p7 to 7.0b3 with modifyfunctio n I think Locksley Woo, CLSA wrote: > One of my programs uses beans with derived properties. Thus, it is common in > this program that multiple slots are modified together. > > Also, I would argue for atomic multiple-slot modification for the sake of > safety. Thank you for these excellent points. It's definitely not to late to go to the "collection of slot names" implementation. = -------------------------------------------------------------------- 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] --------------------------------------------------------------------
