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

Kaspar Thommen kaspar.thommen at gmail.com
Tue Aug 7 14:26:42 EDT 2012


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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20120807/aafa24ba/attachment.html>


More information about the riak-users mailing list