On Jul 7, 3:28 am, Andrea Marangoni <[email protected]> wrote:
> then, i read linuxjournal article and Brad wrote: "All objects are > multiversioned internally and reference counted, so no client can > block any other client's actions. If one client is updating an object > stored in Memcached while a dozen others are downloading it, even with > one client on a lossy network connection dropping half its packets, > nobody has to wait for anybody else.". the article was written on 2004 > and i don t know if is still valid. It's still fundamentally the same design. While it's multi-versioned, there's only one ``correct'' value for any given key. The correct value can change at any time, though. If you imagine requesting a value from the cache and then doing the same again an hour later on a busy app, you will probably expect to receive different values. Some keys change more frequently than others. So say your app gets busy and you rapidly approach values that change multiple times per second. In that case, the values (especially larger ones) are likely to change *while* they're being transferred. However, it'd be wrong to send half of the first value and half of the second, so the server will send the complete value as it existed at the time it received your request. It would also be wrong (at least from a cost perspective) to have a read/write lock on this item. Besides being still yet more memory overhead, a typical application would have writers starving. What it does is far more simple, and similar to how you'd imagine implementing such a thing at the filesystem level. The previous value is simply unlinked from the hash table and lives as long as it's being served up to people. > i also read that there are lock-less mechanisms like CAS: > which of two statements is still valid? could someone explain to me > the first one? CAS as a processor operation is perfectly compatible with the above, but that's not how it's implemented. We currently have a lock to modify the hash table when reading or writing. memcached itself has a CAS protocol operation as a checked set. When you retrieve a value from the cache, you get a unique identifier. If you wanted to perform some operations on the item you retrieved and put it back in such a way that you were sure happened with no other operations between (e.g. if you wanted to make a ring buffer or other counter type thing), you could use CAS to ensure that the value is set iff the retrieved identifier matches. In the binary protocol, we do CAS for every operation where we could come up with any sensible semantics. For example, you can do a CAS delete (CAD?) > Brad also wrote: "If a server fails, the clients can be configured to route > around the dead machine or..." > but i have never read about it in other documentation..i' ve read only about > re-mapping of the keys on the remaining servers... > any suggestion? Yes, that's how you route around the dead machine -- do what you'd do if it had never existed.
