In my opinion, it's probably not a good idea to get too wrapped up with the JavaSpaces implementation detail, since the general problem could happen in a number of ways via DB triggers, rpc by copies, persistence mechanisms, or any number of other ways.
They all could lead to the same situation where you want to replace the object reference of a shadow fact with a reference to a more up to date copy. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Morris Sent: Tuesday, December 11, 2007 7:36 AM To: jess-users@sandia.gov Subject: Re: JESS: Updating shadow facts from object copies Hi Wolfgang, Privately, I've pointed this out to Will as well, but apparently that still doesn't solve his issue. Does anyone out there have any experience in integrating a JavaSpaces implementation such as GigaSpaces with Jess proper? The basic question, apart from Will's current implementation, is: What is the best practice for reasoning with objects in a JavaSpace using available Jess mechanisms? My understanding so far is: * GigaSpaces tosses property change events itself when space objects change. * GigaSpaces exposes no API to allow you to toss property change events from space objects or to wrap space objects with a PropertyChangeListener decoration, therefore you cannot simply definstance an object directly from space. * GigaSpaces writes a copy of an original object into space. No reference to that original object is preserved in the space. Also, Will's team is not currently using GigaSpaces in a distributed sense -- space is in-process in the same JVM as Jess. Obviously, they would like to retain GigaSpaces as a distribution layer in their architecture for scalability. Cheers, Jason -- ----------------------------------------------------------- Jason Morris Morris Technical Solutions LLC http://www.morris-technical-solutions.com On Dec 11, 2007 5:48 AM, Wolfgang Laun <[EMAIL PROTECTED]> wrote: > I have understood Will's problem to be within a single Rete object. > Basically, the Rete.add() method returns a reference to the created > jess.Fact. As a shadow fact in good standing it'll have a slot OBJECT > containing a reference to the original Java object. "Therefore, the > original object is always easily available." (The Jess Manual, 5.3.2) > > > Hal Hildebrand wrote: > > > Wouldn't the fact id be (potentially) different in different > > instances of the rules engine? I believe these are assigned in > > declaration order, so unless every instance is defining instances in > > precisely the same order, then you'd end up with the same logical > > fact having different ids in different VMs. > > > > FWIW, there's a good paper by someone who did something remarkably > > similar: www.waset.org/pwaset/v4/v4-18.pdf > > > > Myself, I've taken another route, which is using shadow facts for > > everything I want distributed. The facts all have generated UUIDs, > > so there's no issues with locally generated ids in a distributed > > system. Then it's a fairly simple matter to translate to the local > > facts when the shadow changes and vice versa. > > > > On Dec 10, 2007, at 1:07 PM, Will Edwards wrote: > > > >> We're attempting to integrate a JavaSpaces implementation with Jess. > >> > >> When an object changes in the JavaSpace we receive a notification > >> that the > >> object has changed and a copy of the changed object which we want to > >> add or > >> modify as a Jess shadow fact in the rules engine. > >> > >> Our problem is that in this environment we do not get a reference to > >> the > >> original object but a new (by value) copy of the object. So, we > >> want to > >> modify the existing Jess fact with the new copy. Assuming we have the > >> FactIDValue (from the original rete.add) is there a reasonably > >> simple way to > >> do this? > >> > >> Currently we are using a FactFilter to get the existing object, call > >> rete.remove() to remove the old copy and then rete.add() with the > >> new copy. > >> This is of course prone to potential race conditions, etc. > >> > >> What we would like to do is use modify() or updateObject() but both > >> of these > >> seem to require that the original object reference be maintained. > >> > >> Thanks in advance. > >> > >> -------------------------------------------------------------------- > >> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > >> in the BODY of a message to [EMAIL PROTECTED], NOT to the list > >> (use your own address!) List problems? Notify > >> [EMAIL PROTECTED] . > >> -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > > (use your own address!) List problems? Notify > > [EMAIL PROTECTED] > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' > in the BODY of a message to [EMAIL PROTECTED], NOT to the list > (use your own address!) List problems? Notify [EMAIL PROTECTED] > -------------------------------------------------------------------- > > -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
