Niclas Hedhman wrote: > Yes, that is roughly a Qi4j picture of what he talks about. > > The real challenge is to find a decent way for "EndPoints" to be able > to locate an Aggregate effectively. An extra network lookup sounds > slow. Having a local copy of the location of all Aggregates sounds > like a "sync" nightmare. Constructing Identities with location meaning > sounds stupid.
Can't we do it as in real-life? I keep a record of your phone nr, and almost all the time that works. If I get a "this nr has been discontinued" I look it up in the phonenr-catalogue, store it for future use, and then call you. So, we only need a local copy of the locations of Aggregates that have been used by local Aggregates. If we try to send a message to an Aggregate and we get "wrong nr"(=404), then we look it up centrally to get the new location, or even brute force iterate through all servers if no central lookup exists. Even with the brute force method the server being checked can say "it's not here, but I know from my record that it's over here" (permanent redirect, 301), so the brute force check can be fairly short. The local "address book" can be size-limited on a LRU basis too. Assuming that not all Aggregates talk to all Aggregates, this should be fine. This way Aggregates should be able to repartition at any time without problems. Makes sense? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
