On 5 Sep 2007, at 06:22, Dustin Sallings wrote:
Doesn't this mean that you will sometimes write a value to a cache, and then later read a value back and get something other than the latest value you wrote? Getting known stale values seems worse than not getting something from the cache.
I was thinking that. It might be better to deny the existence of the key until replication is complete, or make the write synchronous from the client's point of view. I think glusterfs has some kind of transactional integrity for replication between nodes. Alternatively, make the client responsible for writing to replicated servers, which is more scalable. PHPDance does this on top of sharedance. It's not very efficient, but it is reliable.
Interestingly, though it doesn't get much press, MySQL replication suffers the same problem - there is no transactional integrity between replicated nodes - if you write to a master, then immediately read from a slave, you may not get back what you just wrote. The fix there is not to do it and use a unified front end like sequoia instead.
Marcus -- Marcus Bointon Synchromedia Limited: Creators of http://www.smartmessages.net/ UK resellers of [EMAIL PROTECTED] CRM solutions [EMAIL PROTECTED] | http://www.synchromedia.co.uk/
