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

Sean Cribbs sean at
Fri Aug 3 07:49:59 EDT 2012


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>wrote:

> Anyone please?
> On Jul 28, 2012 6:59 PM, "Kaspar Thommen" <kaspar.thommen at>
> 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();
>>   "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();
>>   "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

Sean Cribbs <sean at>
Software Engineer
Basho Technologies, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the riak-users mailing list