[rules-users] More on thread safety of working memory

[Dirk Bergstrom]

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 at juniper.net
> <mailto:dirk at 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 at juniper.net
_____________________________________________
Juniper Networks Inc.,          Computer Geek
Tel: 408.745.3182           Fax: 408.745.8905