The lock will happen every time an "on duplicate key" clause is executed.
Conceptually it's like a checkAndPut, but it's batched. If two threads
attempt to write the same non-existent row, one of them will get there
first and get the lock, while the other would wait behind it (and
subsequently trig
Just to make sure I understand, anytime an atomic upsert is executed Phoenix
translates that into a checkAndPut. Is that correct?
From the Atomic Upsert documentation:
"On the server-side, when the commit is processed, the row being updated will
be locked while the current column values are rea
Out of the box, Phoenix will provide the same semantics that HBase does
for concurrent updates to a (data) table.
https://hbase.apache.org/acid-semantics.html
If you're also asking about how index tables remain in sync, the answer
is a bit more complicated (and has changed in recent versions).
How does atomic update work with multiple clients? Assuming that there is no
matching record to begin with the access won’t be locked. It seems like two
threads could write conflicting data since they both see no existing record
(NER). Is that correct? Or is there something that will serializ
