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 <s...@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.thom...@gmail.com>wrote:
>
>> Anyone please?
>> On Jul 28, 2012 6:59 PM, "Kaspar Thommen" <kaspar.thom...@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@lists.basho.com
>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>
>>
>
>
> --
> Sean Cribbs <s...@basho.com>
> Software Engineer
> Basho Technologies, Inc.
> http://basho.com/
>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
