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.
