Rickard Öberg wrote: > Niklas Uhrberg wrote: > >> A slight variation inspired by the Jini lookup-cache and >> ServiceDiscoveryManager ( >> http://java.sun.com/products/jini/2.1/doc/api/net/jini/lookup/ServiceDiscoveryManager.html) >> >> is to maintain the aggregate locations continuously (or periodically to >> be exact) to minimize latency. >> > > That works too! > > >> This will incur more network traffic just to ping aggregates or their >> "homes" but again, the nature of the application determines if this is >> worth the price. >> I would think that this scenario isn't very common but worth having in mind. >> >> The assumption here is that aggregates can change location, but this >> should be an exceptional case right? >> > > Not really. If repartitioning is seen as something natural, instead of > something that requires major magic, then I can definitely imagine that > if some not-co-located aggregates talk to each other a lot, they would > be repartitioned automatically to the same location, simply because the > usage pattern is such that they talk to each other a lot. Kind of like > people moving to neighbourhoods where other people they like to talk to > live. Makes sort of sense, and in computer terms it would definitely > reduce latency and the need to send messages over the network. > > This is indeed a very interesting approach, I have thought about it but sort of ruled it out as "too advanced" to happen in real life. I hope I'm wrong...
I note that the outset here seems to be "aggregates cooperating" rather than agents/services operating on data. A common scenario in the second approach is that the agent is co-located with one set of data (read entities) during the first stage of a computation, then in a second step the agent can change location to a second set of data residing elsewhere. The important thing is that the data being serialized is just the representation of the result of the first step of the computation. This scenario (which is very useful for massive calculations in multiple steps) seems to be a different one than a few aggregates collaborating to perform some state changes, right? I think it's useful to contrast the two scenarios here. Ideally you would like to address both. >> If we acknowledge the benefit of "shared nothing" architectures they >> should ideally talk to co-located aggregates only (knowing that this is >> far from realistic in many cases). >> > > If you include the above we can have a system that assumes that it is > non-ideal, but at the same time works to make it as ideal as possible :-) > > Yes, /Niklas > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > > _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
