On 7/28/06, <b class="gmail_sendername">Martin Atkins</b> <<a href="mailto:mart@degeneration.co.uk" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">mart@degeneration.co.uk</a>> wrote:<div><span class="gmail_quote">
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It
does mean that whichever node the revision counter is on becomes a
single point of failure for that namespace, too. If that node goes down
you've lost the entire namespace until it comes back up again, at which
point you're worse off because your counter goes back to zero.</blockquote><div><br>
Clients would handle failure by remapping the salt key to another node.
This results in a) having stale keys on different nodes and b) key
resets both at node failure and at node recovery. Poor keys...<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The
only solution that springs readily to mind is to treat the revision
counter like any other cached value and store it in persistent storage
as well as in memcache.</blockquote><div><br>
It's somewhat odd to end up needing capabilities beyond memcached, when
the whole idea was to have an efficient implementation *within* the
bounds of memcached.<br>
<br>
You could of course use mysql as persistent fallback storage for the keys, but that might be a bit too ironic.<br>
<br>
It may be better to implement namespaces directly in memcached, but...
since namespace data may be spread over dozens of nodes, won't these
nodes have to communicate or replicate data?<br>
<br>
Regards,<br>
<br>
Serhat<br>
</div></div>