Unfortunately, we're using the 3.0 version, so I don't think we can use the repository.  That may be necessary with a future version, when we allow users to make their own rules.  Right now, we can be sure that the only rules changes are coming from developers.

Our challenge is that the way we push out a change to the rules is with a central process which does not have access to the working memory (nor should it), it merely compiles the rules and places them in a central location (a database table).  The rules are actually being executed by a series of drones.  Those drones pull the serialized copy of the rules from the common area before they execute.  Since we currently do not allow users to make their own rules, we can safely assume that no changes are introduced that might invalidate the working memories.   So, we haven't tried that, but I'm not sure that we would be able to.

Would it be safer to use the getGlobals() and getObjects() methods to serialize that data, instead of serializing the workingMemory itself?  (and then when we start back up, deserialize the rules, create a new working memory, and setGlobal() and assertObject() all of our serialized data).

... or am I missing something even simpler?

Thanks once again for your very speedy response!


  I think what you are trying to achieve requires some careful planning. If
you use the repository, you have a versioned rule base that make sure you
don't lose your working memory.
  Although, without the repo, only thing I can think of is you making sure
your application always loads the wm into memory, perform the rules
replacement (adding/removing rules), so the working memory gets properly
updated, and then serializes your wm back to the database.... did you tried


2007/6/14, Daniel E Chapman <dechapma@us.ibm.com>:
> Hello!
> We found a problem with the interaction of a serialized working memory and
> updates to the rules.
> Our process involves serializing the working memory to a database.  Later,
> when we load the serialized version of the working memory back from the
> database, if we've updated the rules it will detect that fact and it will
> throw away our carefully preserved working memory.  We suspect this is
> because the working memory maintains a reference to the rules as they were
> when the working memory is originally serialized.
> I'm wondering if there is some way to accomplish what we're trying to do,
> either a way to serialize the working memory with no reference to the rules
> or some way to have the working memory update to accomodate any changes to
> the rules that may have occurred since it was serialized.
> I know that some other rules engines, such as FairIsaac's Blaze engine,
> have complex schemes where you can have versioned rules in a repository and
> update the rules in that fashion.  I'm not sure that we're trying to do
> anything quite so complex, just a way to occasionally push out a new version
> of our rules without having to lose all of the work we've done to the
> working memory in the past.
> (There may come a time where we may intend for the working memories to be
> cleared out, but I think we can do that in a manual fashion when the time
> comes.)
> Thanks for your time, hopefully there's an easy answer!
> _______________________________________________
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users

 Edson Tirelli
 Software Engineer - JBoss Rules Core Developer
 Office: +55 11 3529-6000
 Mobile: +55 11 9287-5646
 JBoss, a division of Red Hat @ www.jboss.com