<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">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).</font>
<br>
<br><font size=2 face="sans-serif">... or am I missing something even simpler?</font>
<br>
<br><font size=2 face="sans-serif">Thanks once again for your very speedy
response!</font>
<br>
<br>
<br>
<br><tt><font size=2><br>
Daniel,<br>
<br>
I think what you are trying to achieve requires some careful planning.
If<br>
you use the repository, you have a versioned rule base that make sure you<br>
don't lose your working memory.<br>
Although, without the repo, only thing I can think of is you making
sure<br>
your application always loads the wm into memory, perform the rules<br>
replacement (adding/removing rules), so the working memory gets properly<br>
updated, and then serializes your wm back to the database.... did you tried<br>
that?<br>
<br>
[]s<br>
Edson<br>
<br>
<br>
2007/6/14, Daniel E Chapman <dechapma@us.ibm.com>:<br>
><br>
><br>
> Hello!<br>
><br>
> We found a problem with the interaction of a serialized working memory
and<br>
> updates to the rules.<br>
><br>
> Our process involves serializing the working memory to a database.
Later,<br>
> when we load the serialized version of the working memory back from
the<br>
> database, if we've updated the rules it will detect that fact and
it will<br>
> throw away our carefully preserved working memory. We suspect
this is<br>
> because the working memory maintains a reference to the rules as they
were<br>
> when the working memory is originally serialized.<br>
><br>
> I'm wondering if there is some way to accomplish what we're trying
to do,<br>
> either a way to serialize the working memory with no reference to
the rules<br>
> or some way to have the working memory update to accomodate any changes
to<br>
> the rules that may have occurred since it was serialized.<br>
><br>
> I know that some other rules engines, such as FairIsaac's Blaze engine,<br>
> have complex schemes where you can have versioned rules in a repository
and<br>
> update the rules in that fashion. I'm not sure that we're trying
to do<br>
> anything quite so complex, just a way to occasionally push out a new
version<br>
> of our rules without having to lose all of the work we've done to
the<br>
> working memory in the past.<br>
><br>
> (There may come a time where we may intend for the working memories
to be<br>
> cleared out, but I think we can do that in a manual fashion when the
time<br>
> comes.)<br>
><br>
> Thanks for your time, hopefully there's an easy answer!<br>
><br>
><br>
> _______________________________________________<br>
> rules-users mailing list<br>
> rules-users@lists.jboss.org<br>
> https://lists.jboss.org/mailman/listinfo/rules-users<br>
><br>
><br>
<br>
<br>
-- <br>
Edson Tirelli<br>
Software Engineer - JBoss Rules Core Developer<br>
Office: +55 11 3529-6000<br>
Mobile: +55 11 9287-5646<br>
JBoss, a division of Red Hat @ www.jboss.com<br>
</font></tt>
<br>