On Wed, Oct 19, 2011 at 5:41 PM, Raffaele P. Guidi <[email protected]> wrote: > Also, on replication/distribution, we have two distinct aspects: > > > 1. *map replication* - the pointers map has to be replicated to all nodes > and each pointer have to contain also a reference to the node who "owns" the > real data > 2. *communication between nodes* - once one node knows that one entry is > contained in node "n" has to ask for it > > > The first point is easily covered by terracotta or hazelcast, while the > second one should be implemented using an RPC mechanism (Thrift or Avro are > both good choices). Another option is to cover also point 1 with a custom > replication built on top of the chosen RPC framework - of course this would > lead to another (do we really need it?) distributed map implementation.
Disagree on this. Be it TC or Hazelcast, they shall cover both the points. Lets take an example of Terracotta. Its a Client-Server architecture with striping on Server side. Now if you choose TC (short for Terracotta), you got 3 options 1. Use DSO or Distributed Shared Object mode - needs instrumentation and other stuff, not recommended 2. Use Ehcache at back, and TC takes care Distributing data 3. Use Map via TC Toolkit TC will not let you know where its storing the key (which infact are stored in HA manner on Server Stripe). That's the beauty of TC. It does the faulting/flushing transparently to the user code. On Hazelcast side, it does allow to know where the key is, but the moment you use its client, it becomes transparent to you. IMHO, using any existing cache solution would complicate the user story. Distribution is a nice to have feature, and infact would lead to a wider adoption :) > > Keeping things like this is easy - of course making it efficient/performant > is a different story (i.e., should I keep a local cache of frequently > accessed items stored in other nodes? etc..). > > Ciao, > R > thanks ashish
