<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    About distributed locking mechanism, you might wanna take a look at
    Google services, something called Chubby? Ctrl + F on that link:
    <a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Distributed_lock_manager">http://en.wikipedia.org/wiki/Distributed_lock_manager</a><br>
    <br>
    Regards,<br>
    <br>
    Guido.<br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 19/10/12 16:47, Guido Medina wrote:<br>
    </div>
    <blockquote cite="mid:50817611.7030205@temetra.com" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      Locking mechanism on a single server is easy, on a cluster is not,
      that's why you don't see too many multi masters databases right?
      Riak instead focused on high availability and partitioning, but no
      consistency, if you notice, consistency is related with locking,
      with 1 single access per key, so you have to decide which one you
      focus.<br>
      <br>
      From the Java world and specifically from the ConcurrentMap<K,
      V> idiom, you use put-if-absent or<br>
      <br>
      As Pseudo language you:<br>
      <b>lock(key) (be synchronized or re-entrant lock, doesn't matter)</b><br>
      {<br>
      ...<br>
      ..<br>
      }<br>
      <br>
      Once you get the lock, you verify if exists, if it doesn't create
      it, if it does, exit the lock ASAP, since it is meant to be a very
      quick atomic operation.<br>
      <br>
      Regarding siblings, Riak allow you to create many copies of the
      same key, and when you fetch that key, you get all the copies so
      YOU have to figure out how to assemble a consistent copy of your
      data base on all the written versions you have (because there is
      no distribute lock per key)<br>
      <br>
      I don't think I can explain in two more paragraph, you will have
      to watch this presentation:
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.slideshare.net/seancribbs/eventuallyconsistent-data-structures">http://www.slideshare.net/seancribbs/eventuallyconsistent-data-structures</a><br>
      <br>
      I'm limited to a certain level...<br>
      <br>
      <div class="moz-cite-prefix">On 19/10/12 16:32, Les Mikesell
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAOAgVpyO8SMy_yZew+7vmFNkA5uW94iuEo10T+K64Wxpwb=pTw@mail.gmail.com"
        type="cite">
        <pre wrap="">On Fri, Oct 19, 2012 at 8:02 AM, Guido Medina <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:guido.medina@temetra.com"><guido.medina@temetra.com></a> wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">It depends, if you have siblings enabled at the bucket, then you need to
resolve the conflicts using the object vclock,
</pre>
        </blockquote>
        <pre wrap="">How does that work for simultaneous initial inserts?

</pre>
        <blockquote type="cite">
          <pre wrap="">if you are not using
siblings, last write wins, either way, I haven't got any good results by
delegating that tasks to Riak, with siblings, eventually I ran Riak out in
speed of the writes making Riak fail (Due to LevelDB write speed?). And with
last write wins then I don't think you would want unexpected results, and
hence my recommendation: We use two things to resolve such issues; in-memory
cache + locking mechanism.
</pre>
        </blockquote>
        <pre wrap="">The problem is where the inserting client should handle new keys and
updates differently, or at least be aware that its insert failed or
will be ignored later.

</pre>
        <blockquote type="cite">
          <pre wrap="">For the last quote, the locking mechanism if well designed will always take
care of that.
</pre>
        </blockquote>
        <pre wrap="">If it is easy, why doesn't riak handle it?

</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>