<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Oops, your right. If you look at how the standard Java client handles it, it maintains a list of active and dead buckets. When working with one key, you could successfully recover the way I mentioned. However, with 2+ keys, you would not be able to detect that the change over occurred.<br><br>So yes, you'd need to broadcast an invalidation. If you partition the caches into smaller caches, rather than sharing one big cache, then the client could prefix the name with the cache node. You can detect the first request where the client makes a migration of the dead bucket back to the active list. In that case, you can apply a flush() on your bucket_partitioned cache since you know its keys are
invalid. I'll have to think about this a little bit more, after the 4th, when the code is in front of me. It may be possible to do it intelligently...<br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Dustin Sallings <dustin@spy.net><br>To: Ben Manes <ben_manes@yahoo.com><br>Cc: memcached@lists.danga.com<br>Sent: Tuesday, July 3, 2007 11:43:48 PM<br>Subject: Re: Handling failovers (rewrite)<br><br>
<br><div><div>On Jul 3, 2007, at 23:29 , Ben Manes wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'times new roman'; font-size: 16px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px;">Well, the way I would resolve it is to have the client delete the key associated in bucket_2 before storing the value into bucket_1. The client is migrating the "dead" bucket back into the "alive" bucket at some point of time. If the key points to a dead bucket, but that bucket is marked for becoming active again, it should take the extra step of recalculating the newKey_1 and deleting it before inserting key_1 into bucket_1.<br><br>This should resolve the issue without broadcasting messages, but
requires that it is handled during the bucket lookup phase.<br></span></blockquote></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>Without recording every key store on every client for every node that was not the primary node for that key, you just can't do that. You also can't assume node 2 was up when node 1 was down. What if a key destined for node 1 went to node 3?<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>The only options are to ignore the problem or broadcast invalidation on mutation.<br class="webkit-block-placeholder"></div><div><br class="webkit-block-placeholder"></div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>(I'm saying that in an extreme hoping someone will come up with something new and exciting).<br
class="webkit-block-placeholder"></div><br><div> <span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-indent: 0px; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px;"><div>-- </div><div>Dustin Sallings</div><br class="Apple-interchange-newline"></span> </div><br></div><br></div></div><br>
<hr size=1>Got a little couch potato? <br>
Check out fun <a href="http://us.rd.yahoo.com/evt=48248/*http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz">summer activities for kids.</a></body></html>