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
listneer
(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
modify()ed?
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
modify() once?
On 2/21/07, *Dirk Bergstrom* <dirk(a)juniper.net
<mailto:dirk@juniper.net>> wrote:
This horse has been beaten pretty hard
(
http://thread.gmane.org/gmane.comp.java.drools.user/3557/focus=3585),
but I
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
objects
need to be updated from external sources periodically. Because each
object type
has a different source, I'd like to parallelize the updates in
separate threads.
Some of the updates involve retraction of expired objects or
assertion of new
ones, but most are just changing fields on already-asserted objects
(all fields
have PropertyChangeListener (PCL) support).
I think that using a SynchronisedWorkingMemory will handle the
assert/retract
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