On 19 Feb 2010, at 08:43, Marcel Reutegger wrote: > think we should try to abstract from a concrete underlying > persistence layer, like we currently do. I know this adds overhead but > it makes it possible to have alternative back-ends. In addition, I > think it helps us to better understand what the contract between the > lower-level API and the implementation above is. e.g. how does > eventual consistency affect the API? how do we have to design it, to > make it useable?
IIUC, provide the API accepts that eventual consistency exists and knows which version of the root node or modification is current then all nodes can act accordingly. It would be very useful to have this built into the persistence API and any journaling/cluster so that other eventually consistent storage providers can be used eg Cassandra or Voldemort. (as well as shared rdbms storage, which would not care) For example, in the current PM, if a node in cluster knows via the journal that an item came from an out-of-date root node, and it also knows which nodes have the required root node, it can go direct just consistent enough location to get that item. I think this is possible in the current PM + Journal impl, but requires some additional information in the events. It would be interesting to know some stats on consistency latency in a real cluster for the above. In Cassandra you can tune it to suite your needs [1], so you could balance locating a node with the right root version with the cost of doing that if not local. Ian 1 http://wiki.apache.org/cassandra/API > > another implementation that comes to my mind is apache hbase.
