Michael Neale was heard to exclaim, On 02/20/07 19:23:
Dirk, it should be OK. As when you assert a fact with a change
(a dymanic fact) it should call the sync'ed modifyObject just like you
would form the outside.
So under the hood, the effect of firePropertyChange() is that the object is
This brings up another question:
If I update ten fields on an object, and call firePropertyChange() for each,
won't that force the working memory to do a lot of extra work, since it will
have to re-evaluate all the affected rules ten times in a row? Wouldn't I be
better off asserting a non-dynamic fact, doing the update, and then calling
On 2/21/07, *Dirk Bergstrom* <dirk(a)juniper.net
This horse has been beaten pretty hard
have a newish angle on it.
My app has a big collection of business objects (1000 of type X,
10,000 of type
Y, 200 of type Z, etc) asserted into a single working memory. These
need to be updated from external sources periodically. Because each
has a different source, I'd like to parallelize the updates in
Some of the updates involve retraction of expired objects or
assertion of new
ones, but most are just changing fields on already-asserted objects
have PropertyChangeListener (PCL) support).
I think that using a SynchronisedWorkingMemory will handle the
updates. Will it be "happy" in the face of PCL changes as well, or
do I need to
do something more?
Dirk Bergstrom dirk(a)juniper.net
Juniper Networks Inc., Computer Geek
Tel: 408.745.3182 Fax: 408.745.8905