Jonathan, Both your approaches would mirror the data to all executors. If you are looking at it this way why not keep the data on the Manager in the first place and avoid the need for synchronization?
Anyway, the way I see it the main advantage of having a distributed memory system is to use the memory of all (or some as need be) machines in the grid to store application data. This means that the data is spread around in the grid, and not replicated. Sort of like a distributed cache. Tibor > -----Original Message----- > From: Jonathan Mitchem [mailto:[EMAIL PROTECTED] > Sent: Wednesday, July 05, 2006 12:47 PM > To: Tibor Biro > Cc: Atali DAOUD; [email protected] > Subject: Re: [Alchemi-developers] data in App.config > > I haven't read your entire response, I will, and probably send another > reply. > > My thoughts were something more along the following: > > Approach 1: > > Each Executor would have a hashtable called ObjectPool. When an > object is added to the pool, it requests an Id from the Manager (which > ensures no Id is used twice). Then, that object is mirrored at each > of the nodes, by being sent to the Manager and broadcast out to each > Executor. > > Each object must support a DataChanged event and handlers for it, > which can be overridden with custom EventArgs to indicate which data > actually changed. When a particular field of an object is changed, > the object sends a DataChanged message/event with custom > object-specific EventArgs and a timestamp, which is sent to the > Manager. The manager then broadcasts that event to all of the > connected Executors, which use the Id to determine which object > changed, and then cast the EventArgs to the appropriate type, and > change the appropriate data. > > There's issues at making sure the clocks are all in sync for the > timestamps (which will be a necessity in order to account for > latency). > > Now, this relies on the centralized Manager paradigm, but could be > extended to a more P2P design where Ids are generated (randomly or via > hashes) and some collision-resolution algorithm is used. > > Conceptually, except for when an object is added, all that is > broadcast is the 'diff' and a timestamp. This would minimize network > traffic, but help ensure synchronization. > > Obviously, there are numerous potential problems with this approach, > because a node may act upon data where changes haven't been propagated > entirely through the system. > > Approach 2: > > However, we may be able to use a compare and swap type of approach. > > Each Executor has an ObjectPool, and the Manager has an ObjectPool. > Changes only propagate from an individual Executor to the Manager, but > not to all the other Executors. > > Then, whenever an Executor requests data from an object in the > ObjectPool, the Executor checks to make sure that the hash of the > local data requested matches the hash of the data in the Manager, and > if they're the same, then it uses the local data in the Executor. > Otherwise, it replaces the existing data with that from the Manager > and uses that. > > This time, again the only time the complete set of data is sent over > the network is on object creation, where it is mirrored by each > Executor. When data is changed, only the 'diff' is sent from the > Executor to the Manager. Then, hashes are sent from the Manager to > the Executor on an on-demand basis whenever data needs to be read by > an Executor, and if the hashes differ, then the 'diff' is sent from > the Manager to the requesting Executor. > > Basically a Just-In-Time approach to distributed data storage. > > Either approach would be completely hidden from the user-developer, > they just work with the ObjectPool using a simple and well-defined > API. > > Anyway, that's a more fleshed out version of what I was thinking. > > Thoughts? > > Jonathan Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Alchemi-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/alchemi-developers
