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. > 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 :-) /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
