Totally understood that it's not worth (or it's rather incorrect) to mix serial and non serial operations for LWT tables. It would be highly satisfying to my engineer mind if someone can explain why that would cause issues in this particular situation. The only explanation I have is that a non serial read may cause a read repair to happen and that could interfere with a concurrent serial write, although I still can't explain how that would cause two different "insert if not exist" transactions to both succeed.

--
Mahdi.

On 2/9/18 2:40 PM, Jonathan Haddad wrote:
If you want consistent reads you have to use the CL that enforces it. There’s no way around it. On Fri, Feb 9, 2018 at 2:35 PM Mahdi Ben Hamida <ma...@signalfx.com <mailto:ma...@signalfx.com>> wrote:

    In this case, we only write using CAS (code guarantees that). We
    also never update, just insert if not exist. Once a hash exists,
    it never changes (it may get deleted later and that'll be a CAS
    delete as well).

-- Mahdi.

    On 2/9/18 1:38 PM, Jeff Jirsa wrote:


    On Fri, Feb 9, 2018 at 1:33 PM, Mahdi Ben Hamida
    <ma...@signalfx.com <mailto:ma...@signalfx.com>> wrote:

         Under what circumstances would we be reading inconsistent
        results ? Is there a case where we end up reading a value
        that actually end up not being written ?




    If you ever write the same value with CAS and without CAS
    (different code paths both updating the same value), you're using
    CAS wrong, and inconsistencies can happen.




Reply via email to