Keeping the data in the Manager runs into the same issue as a central database or fileserver... i.e., bandwidth limitations. Every time an Executor needs data, the Manager must transfer the entirety of that data to the Executor. Versus, if the Executor checks with the Manager to see if it [the Executor] has the most recent version of the data (we could use timestamps or hashes), and only grabs the data if the data has changed.
Over the total system, yes, I'd be mirroring the data, but I also reduce the amount of bandwidth consumed by the Manager as well as time elapsed between the initial request for data and the processing of that data. Redundancy is a bad thing in two situations: a) if it's out of sync, and b) if we don't have the memory to store a redundant copy. I've proposed a couple solutions to keeping things in sync. This approach doesn't address fault tolerance or anything like that, it just reduces outgoing data from the Manager. However, of course, keeping 1 or 2 redundant copies, in a non-mirrored distributed system via your proposal provides fault-tolerance without the overhead of mirrored redundancy, but it does potentially increase the amount of time that one Executor node takes to access common data that may actually be stored at another node. Mirroring with diff-like messaging and a hash or timestamp CAS to ensure the most recent copy is being accessed, if the systems can support it, minimizes the amount of time an Executor can get to the shared data to perform processing. In a real-world scenario, memory may be more precious than bandwidth, at which point centralized storage (at the Manager, or fileserver, or database) or a distributed p2p non-or-minimally-replicated approach would make more sense. If we built a decent programming interface, I think we could leave this as a configurable option on the Manager or Executors. Maybe something that we could even have auto-select based upon the current grid configuration and Executor preferences. (Or even allow for a hybrid solution, with some Executors mirroring, and others just accessing the mirrored copies.) Because which implementation used really does depend on the application and administrative preferences. A machine used for development or CAD visualization or as a server should minimize the Executor's memory usage, but for a machine used by "management" (web browsing, email, wordprocessing and spreadsheet), memory usage by the Executor process is less critical. But, I think we're agreed on the fact that shared memory, via some implementation, is a real feature that's desired. Jonathan On 7/5/06, Tibor Biro <[EMAIL PROTECTED]> wrote: > 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
