Deletion followed by re-addition leads to siblings when it shouldn't

Sean Cribbs sean at basho.com
Tue Aug 7 15:20:40 EDT 2012


The default setting for Riak is to reap tombstones after 3 seconds, leaving
the pristine state for that key. You can change that behavior in the
app.config file.

{riak_kv,[
   %% ...
   {delete_mode, DeleteMode},

]},


On Tue, Aug 7, 2012 at 2:26 PM, Kaspar Thommen <kaspar.thommen at gmail.com>wrote:

> Sean,
>
> Thanks for the explanation. I'm still confused, however, because when I
> insert a Thread.sleep(5000) before the second call to testBucket.store(...)
> then I don't run into the UnresolvedConflictException - looks like the
> deletion of the object somehow got 'propagated' through the cluster and is
> really gone after those 5 seconds. Is this the case? Why?
>
> Also, how can I check if a sibling that I'm getting back is dead (marked
> with a tombstone)?
>
> Thanks,
> Kaspar
>
>
>
> 2012/8/3 Sean Cribbs <sean at basho.com>
>
>> Kaspar,
>>
>> Your code creates siblings because:
>>
>> 1) When a key is deleted, Riak creates a tombstone (with a vector clock)
>> that is not reaped from storage immediately.
>> 2) When store a new value without correlating it to an old value, it is
>> treated as having the "empty" vector clock and creates a sibling.
>>
>> So in the siblings returned, one should be "deleted" and the other should
>> be your new value. You should be able to linearize this sequence by keeping
>> around the IRiakObject you fetched in the second step, and issuing the
>> delete and second store passing that object or its vector clock. I'm not
>> sure how that applies to the Java client, but that is the general strategy
>> in these cases.
>>
>> On Fri, Aug 3, 2012 at 2:48 AM, Kaspar Thommen <kaspar.thommen at gmail.com>wrote:
>>
>>> Anyone please?
>>> On Jul 28, 2012 6:59 PM, "Kaspar Thommen" <kaspar.thommen at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I ran the following Java snippet that creates a bucket, stores a
>>>> key/value pair in it, deletes the key, and adds a new value for that same
>>>> key. The n-value is 3 and all r- and w-values are also set to 3 to ensure
>>>> full consistency (for testing only). Here's the code:
>>>>
>>>>     public static void main(String[] args) throws Exception {
>>>>         IRiakClient riak = RiakFactory.pbcClient();
>>>>         try {
>>>>             // store an object in a new bucket
>>>>             Bucket testBucket =
>>>> riak.createBucket("testBucket").nVal(3).allowSiblings(true).execute();
>>>>             testBucket.store("key", "value1").w(3).execute();
>>>>
>>>> System.out.println(testBucket.fetch("key").r(3).execute().getValueAsString());
>>>>  // prints 'value1'
>>>>
>>>>             // now delete it and store another object with the same key
>>>>             testBucket.delete("key").r(3).w(3).execute();
>>>>             testBucket.store("key", "value2").w(3).execute();
>>>>
>>>> System.out.println(testBucket.fetch("key").r(3).execute().getValueAsString());
>>>>  // throws 'UnresolvedConflictException: Siblings found'
>>>>
>>>>         } finally {
>>>>             riak.shutdown();
>>>>         }
>>>>     }
>>>>
>>>> As you can see by the comment I have added to the code fetching the key
>>>> a second time should, in my opinion, return the new value, but it fails
>>>> because there are siblings. Maybe I didn't fully understand how sibling
>>>> handling works, but I don't see how there can possibly be any siblings
>>>> given that r and w are 3. Any pointers? I tried the LevelDB and memory
>>>> backends, same result.
>>>>
>>>> Thanks,
>>>> Kaspar
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> riak-users mailing list
>>> riak-users at lists.basho.com
>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>
>>>
>>
>>
>> --
>> Sean Cribbs <sean at basho.com>
>> Software Engineer
>> Basho Technologies, Inc.
>> http://basho.com/
>>
>>
>


-- 
Sean Cribbs <sean at basho.com>
Software Engineer
Basho Technologies, Inc.
http://basho.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20120807/18cd37d4/attachment.html>


More information about the riak-users mailing list